Helping small products grow big.
Well I must say, Rakuten is an amazing company and I am very impressed. They certainly know how to put on a conference!
My favourite talk was from Taichi Watanabe who spoke about the 10% Rule at Rakuten Travel. I have asked him to share his presentation, it was gold.
I gave a talk on the agile and innovation programs we run at Atlassian. If you are interested take a look:
Some questions cropped up subsequent to the talk – read the Q&A now.
We are always looking for opportunities to improve what we do at Atlassian. Here is one example from Michael Tokar of the GreenHopper team:
Hey all,
There are conversations currently happening in the JIRA team about 20% time and the way in which it is taken. … I wanted to get a feeling for how you all think about 20% time as it is right now.
Some questions for you to ruminate on as you drink tea. Feel free to discuss or reply privately. For this exercise, just think about the time on the GreenHopper team, not other secondments.
Do you feel like you get “enough” 20% time?Do you feel like you have been “shipping” the fruits of your 20% time? Or do you put time in for not much shippable gain?
What motivates your choice to work on a particular thing for 20% time?
Do you ever feel like your choice in 20% time project will conflict with the product vision of GH / JIRA? Does this concern you?
How much involvement do product managers have in 20% time? How much do you think they should have?
Do you feel like you have great 20% time ideas but you have trouble getting access to the right people to help you finish them?
Is there enough visibility around what 20% time projects do get shipped, from an individual / GH / JIRA family team perspective?
Cheers,
Tokes
I’m talking about the Atlassian experience with 20% time at Rakuten Technology Conference tomorrow. Just thought I would share this email as it is more validation that we are constantly looking for opportunities to improve our practices. Love it.
A great query came through this morning:
Hey Nick, I have a question for you. We’re going through some org changes, and have put together a DevOps team. Traditionally, we’ve only had an Ops team. Right now, the DevOps team is made up of devs, and the idea is for them to work collaboratively with the Ops team (but Ops is still a separate team). Is that how most other organizations structure their DevOps team? Or is it more common for the DevOps team to be made up of both devs and ops people?
—
Chris
My response:
Morning Chris,
When I see this working well it is always Dev *and* Ops. Or, you put Ops on the product team and make everyone responsible for the shared definition of done – similar to incorporating QA, just extending the Definition of Done through to production.
At the end of the day the name doesn’t matter so much as the individuals working together. A shared definition of done really helps drive that alignment and collaboration.
How are things otherwise? Are the teams delivering frequently? What is the goal of the DevOps team vs the Ops team (as it stands today)?
Is your VP Eng on board?
Thanks Chris,
Nick
This is based on what I have seen from visiting other Atlassian customers. I am keen to get your thoughts.
How is your approach to continuous delivery and DevOps structured? Share your views in the comments below.
