YouTube Screenshare of Jer's environment: https://www.youtube.com/watch?v=b43PCy3jrsU&t=48s
YouTube Interview: https://www.youtube.com/watch?v=Z-Lh1NYN7lE
Blog: Blog: https://www.servicenow.com/workflow/ai/learnings-from-when-a...
52 karma · joined September 25, 2014
YouTube Screenshare of Jer's environment: https://www.youtube.com/watch?v=b43PCy3jrsU&t=48s
YouTube Interview: https://www.youtube.com/watch?v=Z-Lh1NYN7lE
Blog: Blog: https://www.servicenow.com/workflow/ai/learnings-from-when-a...
They handled everything for me to make it easier.
I'll add that they pay 100% of my health plan and the birth of my kids cost less than the 3 whole foods bag I bought on the way home.
I thought it might be helpful to share a few thoughts on the article. To do that I've added annotations on the article itself using Hypothes.is an open web annotation service. This lets us have a conversation right over the article. I've added a dozen or so comments, gifs and links to help add color from the Atlassian POV.
You can view my comments and add your own via this link or find me at @seanjregan on Twitter. https://hyp.is/go?url=https%3A%2F%2Fdzone.com%2Farticles%2Fj...
Usually we don't engage in the annual articles by competitors that pin SW industry failures on Jira but in this case it seems a lot of what we've been shipping in Jira Cloud is perhaps still unknown. (And, this annotation tool seemed well suited to this sort of dialog.)
Much respect to the LinearB team. Anyone working to make SW Development better is good in our book. Great products will stand out on their merits among the dev community.
While riding the Jira coat-tails via blog titles is a common approach to generating traffic, I want to also note that Atlassian is very open and we're happy to partner with any vendor that can make dev life smoother.
We partner with GitHub and GitLab as an example. If they can do a better job or a customer prefers their tools then it is on us to 1.) Support them and 2.) continue to up our game.
-@seanjregan Add your feedback, comments or Jira tips to the article here. https://hyp.is/go?url=https%3A%2F%2Fdzone.com%2Farticles%2Fj...
* elastic scaling, * large in-memory caches like memcached, * data locality, * alternative data stores better suited to our data structures such as dynamoDB, * different instance sizes, * dedicated asynch batch processing nodes, * specific instance sizes suited to specific workloads, etc etc
We are also optimizing how and where we store data. We are already storing data in different AWS regions (closer to our customers), however, we are going to also start getting smarter about ensuring the data is actually in the optimal region for the majority of users on a site.
There is also room for improvement in tuning how we query data for issues with many fields, or instances with very with complex permissions enabled. This will require optimizing the SQL we use to retrieve data, to provide all we need to render a Jira issue as fast as possible and exploring other storage technologies for fast data retrieval.
Miss those robots on the spin up screen that you might remember from that past?
It's getting a lot faster. We're going to keep going.
Earlier this year, we announced a migration to AWS which allows us to leverage features such as Auto Scaling our infrastructure and other cloud-scale services. These capabilities have allowed us to improve our availability and reliability.
We are also investing heavily in our frontend technologies to improve the performance of our page load times. For example, the new next-gen Jira boards and view issue pages are all using Server Side Rendering technology to return raw, old-school HTML direct to the browser for rendering. This allows the page to be shown to the user immediately, without the need for multiple round trips back to our servers or CDNs for javascript, css and data. We saw massive improvements in page load times by introducing this for these new key experiences and plan to continue making further similar investments for all other parts of Jira.
Our metrics show we had some of our lowest performance around September last year. Since then, with dedicated investment, we managed to move the needle on performance and are continuing to move it. If you aren't feeling it, let's get in touch with support to see what is going on in your instance.
It's a good example of how being the change you seek changes your POV on something.
I and most of us at Atlassian believe that epowering developers with more autonomy will drive better outcomes, better products, and better teams.
To help resolve these conflict, aspects of Jira needed to change and team culture needs to change.
To fix this we've been investing to democratize Jira's permissions model. We have been focusing on autonomy and flexibility to let any team design the way they want to work while giving administrators the power they need.
The SW biz is a very fast-growing space. When you combine massive growth, speed, and impact it is easy to lose control.
Feeling like you need tighter control means people often try to grip tighter. Sometimes that shows up in insanely complex and structured Jira instances. Sometimes Agile has become more important than agility. Sometimes using Jira has become more important to leaders than the outcomes the actual customer wants. This shouldn't be the case.
It can become easy to over-index on process and control at the expense of agility and software team autonomy. Don't do it!
This results in some over-designed Jira boards and workflows.
Leaders and managers in business and software development need to balance the desire for control with the need for S/W team autonomy. This endless dance between autonomy and control always shows up in every HN thread with detractors saying Jira sucks and fans saying Jira is great but the people setting it up must suck.
There is responsibility all around. Jira, for example, needed to improve the permission model to better empower teams with project level controls. We've needed to simplify the setup and clean up the issue views. These changes in Jira Cloud help admins feel more comfortable delegating more control to teams to design their own way of working.
We can't police how people use Jira in the wild but we can share our POV, our playbooks and we can make changes to the product to make it less likely that managers treat dev teams like factory labor focused on process and efficiency above all else.
A well-running team in a well designed Jira instance should work more like a lab than a factory.
Triads or squads should be able to chase a hypothesis, they should be better able to adapt to new information and respond to change than a factory assembly line. Leaders should be looking for more than process and efficiency out of the team and out of Jira.
How should you handle this?
Make Jira work for you.
Play a role in designing the way you want your team to work. Take the lead in changing the board design or the workflows when your work requires it.
The teams that make adapting to change their competitive advantage make the biggest impact on their company, their customers and the world. But, it takes trust and courage for leaders to create the conditions necessary for this. It means giving software teams a degree of autonomy and flexibility. Mastering this is the core competitive advantage for innovative companies today. These companies retain great talent, they hire great talent, they get great results.
Over the years we've heard the wishlist from Jira users and administrators in large companies and startups.
Make it easier to use and get started!
Give me flexibility and control when I need it!
Let my team design their own way of working!
To bring a new level of simplicity and power to Jira we needed to re-think the basics of the product. We also decided to open up and share our practices to go along with our tools (Team Playbooks https://www.atlassian.com/team-playbook). We needed to learn a few things from the Trello team. We needed to think deeper than new features. The good news is that we've been doing that in a big way and you should be seeing that in the Jira Cloud product you can try today.
A couple examples
Project Level Permissions- Have you ever felt like the Jira you are using was designed for some other team or project? Alert! It might have been. Jira SW Cloud now makes it easy for next-gen project owners and team leads to design their own Jira projects, boards, and custom issue types without creating concerns that it will impact other projects.
Agile features can be turned on and off with the click of a button, so your team can customize to best suit its own unique workflow depending on its maturity level and the project at hand. For example, you can now flip between scrum and kanban methodologies in seconds
You can create issues and columns in-line, without ever leaving the board
Out-of-the-box team filters on every board, such as epic, issue owner, or labels make it easy for anyone to sort and filter in a click, no JQL needed.
You can define a rule to automatically update an issue's field or assignee based on the column it is moved into
You can display issue attachments as card cover images on the board
You can create, edit and delete issue types in independent projects
You can create issue types and customize the fields to suit your team's needs
We've got a lot more coming. The good news is that you can customize, modify, adapt and design Jira Cloud to do pretty much anything you want. The bad news is that means someone who doesn't know what you mean might do it for you if you don't participate.
Building software is complicated work. Jira's secret sauce is the way it simplifies the complexities of software development into manageable units of work that can be predictably shared and worked on by many different teams at the same time. Well designed Jira boards and Jira issues enable collaboration across increasingly diverse software teams that include design, marketing, analytics etc.(via integrations to the Jira issue)
That's a lot of text for a really small text box in HN. I'm trying to stay awake long enough to see the end of the Red Sox game. It's longer than that the typical bit of snark about Jira sucking or your admin sucking or doing work at work....sucking.
My advice:
You can have admin or project admin permissions, you can design the way your teams wants to work, you can integrate the tools like GH, BB, INvision, New Relic, Launch Darkly, etc that your team uses already. You can give the managers the vis they want and need and you can do it without sacrificing the sanity of your team day to day. And, you can use Jira to show whoever needs to know what you've been doing and how it impacts the business.
Jira should feel like the center of gravity that helps all the work your teams are doing hang together across different teams and tools.
People don't want to have to update whatever project management team their management uses.
Good News! That's why this integration exists.
1. This integration lets developers work on their code while automatically sending updates Jira so they don't have to.
2. When you create a commit, it can automatically transition a Jira issue so you don't have to go to Jira to do it.
3. Use smart commits to update the status in Jira, leave a comment, or log time without leaving your command line or GitHub.
4. When you create a branch in BB or GH it will automatically transition the issue in Jira so you don't have to.
5. When you merge a pull request in GH and BB it will automatically transition the issue in Jira so you don't have to.
6. Linking Jira Software to GitHub lets you see branches, commits, and pull requests right on the Jira issue.
7. Now everyone, even those pesky managers and program managers can see the status of work without asking you to take your headphones off, “bumping” their email in your inbox of “pinging” you for the 10th time in Slack. They can see your status right from the board without even clicking into the issue. 8. Search for Jira issues based on related GitHub information, such as open pull requests.
https://www.atlassian.com/blog/jira-software/github-for-jira
Tool X sucks. No, you set it up incorrectly
Tell me why it sucks?
Management sucks
Maybe your team/team and management is the problem.
Oh Hai, GitLab CEO here.
We will build whatever it is you are complaining about.
https://bitbucket.org/product/pricing?tab=host-in-the-cloud https://github.com/pricing