You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
UPDATE: That's a wrap on our AMA. Thanks for taking part and asking such interesting questions!
Have you ever looked at a company, and thought to yourself, wow, now that’s a real dream team, building great things…what is the secret to operating with both the agility of a startup AND the durability of a market leader?
They’ll be answering questions live on February 24 at 2 pm PT, so start posting your questions now here!
Find out how they use Team Central to empower their teams to find the balance between autonomy and coordination. Work only gets more challenging with distributed colleagues and as a company grows. But when everyone can quickly communicate progress and provide context in repeatable ways, companies can unlock their teams' potential and move work forward.
Drop your questions in this discussion any time before or during the AMA. Be sure to watch this page for other community members' questions and up-vote those that you find interesting.
PS: Mention "Atlassian AMA" and LaunchDarkly will double your free trial period!
What tools do your teams use and how do you bring all that into Team Central to give peripheral teams the right amount of information to keep things moving?
We are in the early stages of adoption of Team Central at our company and occasionally hit a hurdle in our adoption. What was your strategy for adoption of Team Central and what challenges (if any) did you need to overcome when bringing your various teams into the platform?
Hi @Andrew Kendris,
At Turnitin, we use Slack across all functions. Engineering and Product use Jira and Team Central, whereas Marketing uses Asana and Sales uses Salesforce.
In terms of other teams adopting Team Central, we’re seeing it spread from the ground up (not top-down mandated). Once the CTO was able to get structured updates from some of his teams (ie: customer impacting teams had adopted Team Central but Infrastructure, AI teams had not) the other teams began to ask about Team Central.
We had always structured the internal marketing of Team Central to be usable to anyone that could find value in using the product.
One struggle that we do have is that other teams want to be able to use the data we are entering into Team Central but our processes aren’t currently supported so we have to say No. As an example, we work with the following teams: Product Marketing, Support, Customer Experience. We have to explain to them how to interpret the Status values and the Target Due Dates, so that they understand that the Due Date does not necessarily mean “ready for customers,” etc.
As always, the most challenging part is to get the updates that we need in a timely manner and of course, projecting dates with accuracy. As Team Central becomes more integral to our cross-organization communication process, the value of the data that is entered into the tool increases. We now are using the data to create dashboards for Product status meetings and Organization communications working to drive compliance from the top-down.
Thank you so much @Leah Picone - this is very helpful and a good check of our internal approach!
Glad to see we are on a similar page when it comes to adoption strategy because ours is also from the ground up (we originally published a Confluence Page with background on Team Central to get the ball rolling and had that had some immediate success). From what you closed with, if you get enough buy-in from the ground up, the top-down reporting and compliance becomes a smooth experience 🙂
We do find that defining/aligning values has a bit of confusion on our side too across teams and it will be great when Team Central date values to possibly link with Jira start/end dates at the epic level.
Hi there- What problems is Team Central solving for your company? Is Team Central replacing any other tools?
For us, Team Central has replaced a lot of manually maintained Confluence pages. It’s superior in a lot of ways:
We were doing some of those things before, but much less consistently, with less visibility and more work. We still write a ton in Confluence, but we use it much less for status reporting than we used to.
Currently, Team Central does not have an integration with the Jira Cloud Insights feature. That feature was designed to provide insights within a team. In contrast, Team Central provides a communication layer between teams.
We believe in encouraging teams to communicate clearly using the right level of detail for their audience. In this case, curating a weekly written update instead of automating the number of issues completed, the detail of tasks or percentage completion is how we believe effective communication works to stakeholders & dependent teams. Here’s a helpful article that goes into more detail on this topic.
However, we do plan to build out our Jira integration later this year to help solve problems of duplicate information entry by syncing information (for example dates changed on your Jira epics could also be reflected on your Team Central projects)!
We are using Insight in the cloud for our CMDB. We currently have our org structure (staff, reporting structure, departments, functional teams etc) in Insight. We would love a way to sync that information with a tool like Atlas. We will be syncing Insight with other Business systems and we would need a way to sync Insight with Atlas. Other wise I am not sure how practical it would be for us to migrate to this amazing tool. I am sure another of other organizations have the asme issue given a LOT of people are using Insight in this way. I actually saw a video by someone in Atlassian who is using Insight int he same way as well. So some of their departments seem to be in a similar boat as well.
I'm experimenting with team central to provide project updates. The tool forces us to be brief, so writing the update isn't a lot of work - one of it's best features I think.
Do you find the updates are sufficiënt to keep the stakeholders who receive the updates well informed? How are you crafting the updates so the updates are detailed enough to keep the stakeholders happy and informed.
Hi @Rob Buijs , thanks for the question!
I am one of the primary consumers of the updates, and I find the two-sentence explanation to be the perfect length 95% of the time. The other 5% I can use the links to read the spec, or our issue tracker, or just ask a follow up question right there. TC does allow you to include longer text if needed, but it rarely has been for us.
I would encourage you to think of this standup-style: what we did (did we hit last week’s target?), what we’re about to do (this week), and if there is anything standing in our way. That’s important information, but it’s the most boring thing in the world to sit in a room where a bunch of people go around the room to report status on a bunch of unrelated projects. With TC, you can follow the projects that affect you, and you can ignore the ones that don’t.
@Rob Buijs I would say that in our organization we have definitely experienced struggles in getting the updates to be "punchy" and informative. We continue to provide feedback to those giving the update or ask follow up questions to get to the clarity needed for the update stand alone in the tool. Not everyone is used to synthesizing the progress of their work over a week/bi-weekly time period, so it is a muscle we are working to build up.
We definitely use both Confluence and Team Central. Confluence is for developing ideas, making plans, updating How-tos, communicating policies and successes.
Team Central, on the other hand, is specifically about a weekly-cadence status communication -- something we used to attempt in Confluence but it often got lost in the noise, or people were less than rigorous about it. By giving a very tight format and schedule, Team Central has helped dial this practice to be maximally useful and minimally burdensome.
Great questions @Vaishali Patil we often consider which products we can retire as we add a new product to our toolkits.
Scenario 1: Single feature tracking
Prod+Eng Org had been using a single Confluence page to track the status of the Feature deliveries. Our solution lacked traceability, accountability and had a host of other issues.
Team Central started as an easy, immediate win for Product because we were able to show value to the users with this basic sales pitch: The only way to reduce the questions and effort on your team, and therefore focus on the work, is to provide a location for people to find the status on the projects that they are interested in.
Scenario 2: Tracking Large Projects with many teams and dependencies
Our Engineering Project Management Office, engineering leads had been creating a single Confluence page which would contain synthesized data from JIRA, other Confluence pages, etc. with embedded query results to show the progress of each subtracks work towards the overall deliverable. This information would be presented to the VPs/CTO to track progress. The above activity was very manual, and lacked scalability.
After finalizing our requirements to present to the VPs/CTOs we were able to create Team Central projects, managed by the Engineering teams to satisfy the details and information required. The CTO is now looking for other teams to present similar project updates in this same manner.
Scenario 3: Intended audience, details to communicate
When considering which of the many Atlassian tools to use to solve for each situation, we like to keep the following in mind.
First, understand how Confluence is used within your organization. We knew that not all of our teams utilize Confluence within their workflow, which we take into consideration when evaluating what we are communicating. We consider the type or volume of information which is posted to Confluence as complementary to our Team Central projects (through the many links we add).
For how we use Team Central, we internally market the tool as a single source of truth for the content it manages. We view Team Central projects as having a specific life span, which helps our stakeholders have confidence that what they’re reading is the most recent update. For us, Confluence pages live for eternity, and are better for giving more in-depth information.
For a while now we have been saying (not sure if we really are doing it..) that we are doing "agile development" for a few customers. For one of them we have had a number of 2 or 3 weekly Sprints containing development that is delivered based on a spec.
We invariably find that some of our development delivered in a Sprint "fail" in customer testing - at times due to bugs (our fault) but at times also due to spec. being ambiguous or due to new requirements.
So my questions is : Does Agile mean incremental development in the sense that some features can be perfected (if it is ever possible) after a number of Sprints and it is considered normal within Agile development because the focus is on continuous development, delivery, testing and refinement ? Or have I got it completely wrong ?
Bhaskar Jani, Development Manager.
Hi Bhaskar, thanks for the question!
Agile means a lot of things to a lot of people, but I personally think you can learn a lot from going back to the very beginning and reading the Agile Manifesto and the original Kent Beck “Extreme Programming Explained” book. They explain the principles behind the practices, and why Agile can work. They also explain some of the requirements for successful agile teams – and one of them is having a “customer” on the team. To build software successfully you need constant communication, and the more frequent you can have those cycles with the customer, the more quickly and successfully you will be able to create exactly what they want.
Delivering new software for acceptance every two weeks is better than every two months. But getting feedback from your on-site customer every two hours is better. Whatever cycle you use, Team Central helps us keep all of the “customers” in the loop in an incredibly transparent and efficient way.
Software built by teams is organic. It grows over time, and it’s the responsibility of the agile team to make sure it’s growing in the right direction. Each sprint check-in is an opportunity to test what you have built against the customer’s reality – a chance to refine your product closer to what meets the need. As you progress each week, your team learns more – about the tech, about the product, about what the customer really wants – and you should be adjusting constantly as you learn. That’s the most basic definition of Agile.
I don't think there's a universal definition of a 'pure agilest.' I think we tend to over-complicate where we are going and how to get there. Each methodology has a place in the overall process — even the dastardly “waterfall” method, especially if there are any dependencies.
I’ve been in an organization where teams hid behind being ‘agile,’ creating an environment where leadership did not standardize our tools or processes, require any documentation nor create a plan. It went about as well as you can imagine.
I've also been at another organization also claiming to be agile. Imagine the surprise of their customer when we wouldn't have enough time in our agile timeline to implement payment services.
In short, I like to keep the 4 values outlined within the Agile Manifesto (https://www.atlassian.com/agile/manifesto):
That is, while there is value in the items on the right, we value the items on the left more.
Thank you @Eileen Changsut
Do you use Team Central for your project intake process? I've used forms in the past, but I think that Team Central could be the entry point for these requests while keeping everything centralized.
Hey @Carlos Garcia Navarro , We don't use it like this, and Team Central doesn't really allow for that kind of "workflow" -- which I think is part of it's strength. It's a communication tool, not a workflow tool.
However, Team Central _does_ force you to answer "What are we doing?", "Why are we doing it?" and "What does success look like?" For us, these are questions that we asked at the top of every product spec before Team Central, but I think it's even better to answer them in Team Central. It's the canonical "home" for any project and it's important to keep everyone aligned on the core reasons why we are doing this.
+1 to Jonathan!
Team Central is intended to be the communication tool to align teams on a common language (using the 3 same questions for every project started). A project is usually created once the work has been committed or kicked off; when you're at a state where your project owner could answer the questions of what are you doing, why are you doing it, how will you measure success. This is often a step later in the journey than project/idea intake.
Since idea intake is a team-specific activity, we actually don't think that needs to be centralised across an organisation. Teams should feel empowered to collect feedback or do project intake wherever suits their team the best and then turn that into a Team Central project when they need to start communicating on the progress of it to stakeholders or dependent teams.
We have another new product in the Atlassian suite, called Jira Product Discovery which helps to solve the discovery piece around collating feedback, tracking feature requests/ideas and prioritising them.
I like to know how to help teams move towards, create and encourage an agile mindset esp with people who can’t see agile past ceremonies and acronyms. They often see it as good thing but for others or think it’s not possible unless everyone in the business was to change or we had more people.
@Usman L One of the biggest things that comes to mind when I think of agile is that it is 100% a team sport. And by that I mean that engineering/technology can't do it alone - you have to bring product team and other business teams along. One of the ways to do this is to Plan Big and Implement Small. Make sure you cast the vision of what you want to deliver to your stakeholders and then show them the value of developing in an agile manner through quick wins (implement small). Be sure you aren't just talking about the benefits of agile but are actually showing the benefits to your stakeholders...
Hi @Paul Saunders , thanks for the question! We have a few folks outside product delivery who are beginning to adopt Team Central. It does seem to be easier to adopt in those parts of the org who have invested in a culture of writing and it's comparatively harder in the parts of the org who rely more of face-to-face interaction.
The good news, though, is that every team's usage of TC is exactly the same. Team Central doesn't really care what kind of projects you are doing. There's nothing "engineering specific" about it. If you are doing work over a multi-week time period, and you have folks in your org who might want to know how that work is progressing, Team Central can help!
Posting this again as a proper reply this time!
No signup link necessary! You can ask a question by writing one as a comment to this post.
Jonathan, Leah and Kim will answer questions live on February 24 at 2 pm PT by responding to this post's comments in threads, so feel free to ask question(s), save this post's link and check back in on that date and time!
Hi @Vivian Chau , sorry if I misunderstood, but will a link to attend the AMA session be made available on Feb 24 at 2pm PT in this thread? All other events I had joined had an invite and a link to connect. Thanks!
No worries! No, there won't be a link to attend the AMA session because at 2 pm PT today, our featured guests will start responding to these questions on this page. I'll update the top of this post to indicate that the AMA is live and when it has been concluded. Hope you can make it, cheers!