Hi! I'm Dom Price, Atlassian's expert on team culture, agile and the future of work. AMA

Viewing page 2 of 3

61 comments

Comments for this post are closed

Community moderators have prevented the ability to post new comments.

As a member of the agile team, we use a variety of visual kanbans.

In addition to Jira's Scrum Board/Kanban, the physical whiteboard is also the way we use it.

I think whiteboards are more conducive to team focus issues and faster writing in daily standing meetings.

I want to know if everyone will use it like this? In what scenario will Jira's board be used, and when will other categories of boards be used?

Thanks.

Like • like this

As a start, whiteboards are a great way of bringing a scrum or kanban practice into your building. When you start standing around a whiteboard, you end up having conversations about how your team is working that you probably never had before.

Jira's Scrum and Kanban boards are great for more mature teams with agreed upon processes.

We also recently created an alternate board type in our Cloud version of Jira (what we're calling the agility board for now) for teams or projects that aren't as clear about their processes. It's entirely configurable, so you can add/remove/customize your workflow stages, add or remove sprints or a backlog, etc. Basically it lets you define the workflow that works best for your team and the project at hand. I think this board would be appropriate choice for projects that aren't clearly Scrum or Kanban.

How do you instill a sense of psychological safety at Atlassian?

Like • like this

I love this question. THANK YOU for asking it.

You can't run a top-down psychological safety initiative. It just doesn't work that way. Instead, we work to make sure individuals are contributing to a culture of safety in a few key ways.

First, we embrace honest failures as a learning experience. Nobody has ever been fired from Atlassian for taking a calculated risk that didn't pay off. And blameless post-mortems? You bet. In a failure-tolerant culture, it becomes far easier for people to admit when they've made a mistake. That admission, in turn, builds trust with the people around them and makes them feel like they can admit their mistakes, too – and the upward spiral continues.

Second, we have an unofficial company value: "seek first to understand". In other words, start with the assumption that the person you're upset with is NOT an idiot. Ask them why they did what they did. Your desire to lash out will probably disappear immediately.

Third, we focus a lot on belonging. So you'll find everything from informal mentoring circles for women on our technical teams to prayer and meditation rooms in our offices (and at events like Summit). We want every Atlassian to bring their true self to work. Fly that freak flag proudly. Because if you see the people around you being themselves, you'll feel like you have permission to do the same.

I can't overstate how important psychological safety is for teams and companies that want to move fast and do big things. In today's fast-paced environment, a culture of fear is essentially a death sentence.

Great points there

Wish I could click "Like" on this answer, @Dominic Price!!

When we started with Agile, we got support from a well-respected consulting company. Their strongest advice was to not use electronical boards, just real boards with real paper issues. And we still have a lot of these, but also virtual boards in Jira.

What do you think, is better? Would you say, issues should exist both in Jira and also on a real-life board?

Like • like this

Interesting question - we have big discussion about that right at the moment in our company. Looking forward to @Dominic Price answer!

Based on this, is your team fully co-located? None of the members of my team are co-located so this might be somewhat interesting for us :)

Yes, we are all working on the same place.

The right board for tracking work is the board that members of YOUR team will keep up-to-date. Some teams are really into physical boards where you move index cards from column to column. It's tangible, it's satisfying, it's easy. It's also completely unsuitable for distributed teams and it lacks a paper trail, so it's not a great fit for all teams.

Whether you go physical or digital, show a bias for low overhead. Which means having ONE board. One source of truth. One place team members update their status. Don't create busy work for yourselves.

In my experience, the best teams have the discipline of regular updates, openness and one source of truth.

Sorry @Dominic Price, I have a follow-up question;

Q: What predictions can you make for the changing models for work and work structure?

Like • like this

I believe that work will become more distributed, and there will be less of a focus on working hours/office, and more on energy, work anywhere, and contribution to outcomes.

I think the rate of change of roles and jobs will increase, and we'll need to re-skill more.

I believe we need to develop more discipline in being connected, and disconnecting, so that we actively manage mental wellbeing.

We need to focus on being effective, and efficient, when I think history has focused on just efficiency.

Screen Shot 2018-08-09 at 3.00.26 pm.png

Hi @Dominic Price,

In the (almost) true spirit of a Reddit AMA, I have an Agile/not Agile question for you...

I've been a project manager for 15+ years and as such many of the things I do at work bleed into my home life. For example, last weekend I was told that I do not need a Kanban board to clean out the garage!

How does your work as an Agile practitioner help/hinder what you do during your non-working hours?

(On a side note...my wife also recently told me we should consider going back to Waterfall with full-on Stage-Gate approval meetings before I start any more projects.)

Thanks!

Like • like this

That's kind of hilarious. And I can relate!

I'm constantly after my kids to finish one thing before starting another, and in my head, I picture a Kanban board every time! The WIP column is overflowing and the Done column is oh-so lonely.

Confluence confessions... I plan everything big at home using Trello. If it isn't a card it doesn't exist.

That said, my vacation planing boards are so awesome, I've got multiple friends that have asked for access so they can see where to go on various road trips I've taken.

@Joe Tong Now *I* want to see your vacation boards :D

Hilarious and insightful!

My values in life very closely align to the Atlassian values, which makes for an easy life. But when it comes to me outside of work, I'm a very different proposition...you know they say never buy a house off a builder...never go to a dinner party with a chef...don't buy a car off a mechanic...don't let me plan anything! Ever.

The closest I've come to doing this, is using Trello boards to organise Christmas dinner (everyone brought a dish) and a spotify playlist.

I did try a health monitor in a relationship once...not so good.

If you want some inspiration, try this guy:

https://www.atlassian.com/blog/inside-atlassian/ran-kids-like-atlassian-team-month

@Joe Tong if you don't write a community article about your vacation boards, I'm going to be very disappointed.

@Bridget ^^^

Do It! Do It! Do It!

Excuse me for my english in advance :)

Tipical situation for companies nowadays:

A company transformation project. They want to transform a traditional process to an Agile methodology. They want to train their people in Agile and use new tools adapted to DevOps (e.g. BitBucket, Github, Jira....)

Inconvenient: They use a waterfall project management to control this project (e.g Prince2).

How would you approach these risks as an Agile coach?

Extra costs
Delay in delivery dates
Change culture of teams
Customer expectations
Change control

Thank you! And good luck!

Like • like this

Some questions you can ask yourself upfront:

Is the team is aligned on the goals of the project?
Do you have a balanced team to get the work done?
Has the project been effectively communicated/articulated to stakeholders?

One way we've managed these risks upfront is through using our Health Monitor which checks key team attributes such as shared understanding, managed dependencies, balanced teams, velocity, proof of concept - all of which can get your team started on addressing the risks you've mentioned.

If you have a team that transitions to agile - how do you evaluate the effectiveness?

How long do you wait for results before deciding whether to keep new practices or revert back to old?

Like • like this

Great question @Lauren Schroeder! Having effective metrics showing positive results is a great way to build momentum and support. I believe 3 sprints or at least a month should start to give some indication as to whether the change has been effective or not. This can be greatly affected by the commitment the team has to change and the new methods.

Thanks @LarryBrock! I like that last caveat.

If I had to choose one, I'd say the simplest way to evaluate an agile team is their process efficiency. This is the number of valuable work items(one user story or ticket) divided by the number of calendar days it takes ship. So 1 user story per day is 100% efficiency, 1 user story every four days is 25% efficiency. You can quickly evaluate your transition to agile by charting the increase in process efficiency. Then, you need to drill deeper and find ways to increase the value of the stories you ship.

My team does a monthly Team Health Monitor to check in on what practices are working for us on a regular basis. Try one out and let me know how it goes!

When will we be seeing markdown in Jira?

Like • Ash Moosa likes this

Hey Louis, unfortunately we can't disclose our future roadmap as we are now a public company. Check out Jira.atlassian.com for a live repository of all customer requests.

1) Can Agile work in a "team" where 80% of work has to be assigned to 1 or 2 specific people rather than everyone working form the same backlog?

2) Can you recommend any blogs or videos that show what a good retrospective can be like? My only experience is with post-implementation-review style meetings where we make a note of things we could have done better and promise not to repeat the same mistakes in future.

Like • like this

Thanks Kat

Yep, sure can. That's often the situation with cross-functional teams (e.g., 2 developers, 1 designer, 1 marketer). I recommend putting everyone's work items into the same backlog so it's all collected in one place and you're all looking at a single source of truth. During spring planning, just be mindful of how much capacity you have in each area.

And due to the differences in skill sets, cross-functional teams that bring specialists together have the advantage of having more diverse ways of thinking than teams of people with homogeneous capabilities.

Regarding retrospectives, I don't have a video handy, but check out our page on retros in the Team Playbook: https://www.atlassian.com/team-playbook/plays/retrospective There are instructions for basic retros, as well as a bunch of variations worth experimenting with. The real key, though, is to hold retrospectives regularly so you're holding yourselves accountable to the changes you promise to make and follow-up actions.

Hi @Dominic Price

any tips for new build teams (most of them non-technical and a little bit oldschool) that want to start off getting agile? Do you think external support is needed or can a team reach this together?

Looking forward for your answer.

Like • like this

Hey Fabienne.

What I find is most important to a team's agile journey, is starting off on the right foot, by setting up a time to introduce everyone to the principles of agile. Even a quick Google search of the "agile manifesto" will help your team grasp what your North Star is as you make the process your own.

I think external support is helpful in cases like this, but that doesn't mean you need to hire a consultant. If there's one person on the team or in the larger organization with previous agile experience, try recruiting them as an informal agile coach as you're transitioning. Alternatively, a person on the team who is inexperienced by highly enthusiastic can serve as the team's "champion" for agile.

The key is keeping momentum and morale high during the transition. As long as you're making steady progress in your agile journey, you're probably doing it right.

Thanks so much for your answer @Dominic Price - makes me feel a lot better about our journey we already started :)

I will take your advice and will look for other people here in the company that want to support our group.

As long as you're making steady progress in your agile journey, you're probably doing it right.

Love it - this will become a printout on my desk!

Hi @Dominic Price !

What will be next after Agile process implementing? How to management will measure scaling teams/company?

I mean SAFe or LeSS for the IT - service, prduct deevelopment, how to understand proactively when we need to review our process.

Thanks

Gonchik

Like • like this

Hi Gonchik,

There's really no "done" in implementing agile processes as you should be continuously improving. Two things we are thinking about beyond agile for teams is agile for non-tech teams and agile at scale (across larger and increasingly complex organizations). Watch this space for more of our thoughts on what's next in those two spaces!

As far as proactively reviewing team processes, I am a huge advocate (as you can see in many of my other answers) of getting in the habit of doing a monthly Health Monitor with your team. It's a good way to make sure you are doing regularly thinking about not just what you are building but how you are working.

Couple questions!

1) What are some common myths about agile that you think are holding back teams from moving into agile?

2) Not really agile related, but on the future of work... what do you think the state of remote work will be in five years? Will people still come into offices? What kind of obstacles will prevent a fully remote workforce?

Thanks! Looking forward to this!

Like • like this

One myth holding people back is the idea that agile is only for software teams. Not only is this patently untrue (HR, Marketing, Design... all these disciplines can benefit from iterative planning and execution!), it's creating friction within organizations. If your software team wants to work in an agile way, but your design team doesn't think agile is for them, the two teams will be consistently out of sync, and massive headaches will ensue.

Regarding remote work, it's only going to be more prevalent. First, there's a war for talent going on. If you're limiting yourself to candidates to live in your area or are willing to move there, you will struggle to find the right people. Second, the tech that supports remote work and distributed teams is improving by the minute. We have loads of digital tools for sharing our work, and video is so easy these days, you can fire up a call with one click. Third, urban office space ain't getting any cheaper, even in relatively low-cost cities.

I'm not sure anything exists to fully prevent an all-remote workforce. But I will say that relationships are extra-important in this context. In my experience it's best to spend time together in person once in a while, especially when the team is new or a new member joins. Kick-start those relationships in person, then maintain them remotely.

Love this! Thanks Dominic!

Hi @Dominic Price

You're all over crushing it in the world of spreading the news about all the ways the teams can collaborate and be awesome together. The real question is, where do you get all of your cool tshirts and how can we get some...?

Cheers!

-Billy

Like • like this

You really know how to make a bloke blush, Billy! As far as Atlassian swag goes, there's an app, well website, for that! https://atlassian-swag.mybrightsites.com/products?s%5Bf%5D%5Bc%5D%5B%5D=%2FApparel

Woot! Thanks for the link! I'm going to see how much we can score for the AUG Members ;)

My organization is stuck in what I phrase as an "Agile-Fall" world. We've adopted methodologies depending on the team working the project which has allowed some flexibility; however, in doing so it has prevented cross-functional teams from being consist.

As an advocate of agile, how can one effectively outline and articulate the benefits of agile even for teams (e.g., Infrastructure) who claim they will forever be waterfall?

In order to be considered agile what are the basic requirements?

What is the greatest difference between DevOp and Agile teams?

Does agile work for projects outside of software development (e.g., business requests)?

If agile did not exist what methodology would you use?

What is the best practice or advise for teams that are reluctant to maintaining a backlog?

Like • like this

Hey LeKisha lots of good questions in here.

As an advocate of agile, how can one effectively outline and articulate the benefits of agile even for teams (e.g., Infrastructure) who claim they will forever be waterfall? I'm going to tap into my years as a management consultant to answer this question, the key to convincing someone of the benefits of agile is to first understand what's important to them and then to meet them where they are. Don't try to go full Kanban on day one, figure out how to apply the agile principles to solve the team's most pressing pain points and go from there. Frameworks and methodologies aside, the key is whether teams are successfully delivering customer value.

In order to be considered agile what are the basic requirements? The most basic requirement is the mindset. Values such as collaboration, learning, growth, customer centricity should be at the heart of the practices a team adopts.

What is the greatest difference between DevOp and Agile teams? A simple way of describing is this is that DevOps is about shipping the software faster with lower bugs and agile is about shipping the right thing using fast feedback loops, relying on DevOps for the fast feedback loop to be possible in most cases.

Does agile work for projects outside of software development (e.g., business requests)? Sure, agile is an approach for dealing with uncertainty by continually inspecting and adapting your outcome and your processes to make them better. I used agile to remodel my apartment with the contractor while I was in Seattle and they were in London, UK. We used Scrum as the approach and used video conferencing to overcome the distance. Daily Scrum every morning my time and building the Sprint backlog weekly. In the Sprint demo at the end of the week the team would walk around with the webcam demonstrating the completed work. We then retro'd on what we could do better next week. I didn't use the Scrum words with the contractor, he liked the approach - well he said he liked the approach :-)

If agile did not exist what methodology would you use? It would look like agile .

What is the best practice or advise for teams that are reluctant to maintaining a backlog? Perhaps start with seeking to understand what's blocking them from maintaining the backlog, whether it's a principle or practice challenge. If it's principle help them understand the benefits (that are aligned with what they value) and if it's practice figure out how to communicate what efficiencies will be gained, even if it means a temporary slowdown.

Ok: not a question. But! Several people have already asked for the slide deck from Dom's keynote at Agile2018. You can view it and download it on SlideShare. (The speaker notes have been tidied up and are available in the "Notes" tab.)

"Stay agile, San Diego!"

Like • Mary Raleigh likes this

There's currently a twitter discussion going on around agile and capacity planning. Some companies find capacity planning to be needed while others say it goes against the whole idea behind agile.

As someone that helps to administer a JIRA instance, I see requests for plugins that help to do capacity planning. When able, we want to provide projects the tools they need to bring success, but don't want to be assisting with them going in the wrong direction.

Would love to hear your take on it.

Like • like this

Me too!

People say the same thing about roadmaps and a part of me agrees completely. Another part of me has seen the value of a roadmap to help communicate a possible scenario for the delivery of a product to those that otherwise wouldn't understand. The same is likely true in this capacity planning discussion.

I'd encourage you to educate yourself on how capacity planning contradicts the agile values or your agile process and make that risk known to the people excited about the capability. I always share how a roadmap is a guess and remind people that this roadmap will be out of date almost immediately.

A reminder like this puts the risk on the requestor. I hope this helps.

Thanks! As far as educating myself on how capacity planning contradicts the agile values, do you have any specific recommendations for reading material in this area? There's so much out there, I feel like you can find whatever you need to backup any way of thinking, so want to make sure I start on the right path. Thanks again!

As one of Dom's peers who also studies the future of work, I thought I would chime on this interesting question. I've linked to some articles in my answer below. Each is about a 5 min read.

For my part, it isn't that capacity planning in the abstract contradicts agile values. Indeed, one of the principles in the Agile Manifest smells a lot like the idea of capacity planning: "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely." This implies that you have to match demand to capacity.

On the other hand, traditional capacity planning approaches tend to work against these 2 values from the Agile Manifesto: "Individuals and interactions over processes and tools" and "Responding to change over following a plan". Specifically, traditional capacity planning assumes people have certain specializations and work can be matched to those specializations by managers. The agile community doesn't accept those assumptions. For specialization, most agile coaches would talk about "generalizing specialists". For matching skills to people, most agile coaches would talk about "self-organizing teams". Fundamentally, the mindset behind traditional capacity planning is that management's role is to optimize the utilization of resources. The mindset behind agile is that teamwork is adaptive so capacity isn't a fixed quantity, and that what needs optimizing is the throughput of value in terms of working software.

So how does the agile community reconcile the apparent contradiction between "sustainable pace" and "capacity isn't fixed"? As a start, Scrum changes the units of planning. On the demand side, plan in terms of things that are valuable, like user stories, rather than tasks for a specialized function. On the supply side, plan in terms of teamwork, rather than tasks for specific people. Other agile techniques like Kanban and Mob Programming do away with even those hints of capacity planning, favoring a focus learning about priorities as they go, rather than making big plans upfront.

One of the things about Dom's answer, and your observation about the about the breadth of agile opinions, is to realize how agile, as an adaptive technique, is different from the idea of context-free "best practices". A practice isn't best because everyone in the industry does it. It's best because it works for you and your organization. So I hope the above links help your best practice for capacity planning.

From a Project Management POV, regardless of methodology, you need to have an idea of how long something will take (so you can inform customers, look at budget etc.). This means you need to be able to estimate how long it would take (usually a team of people) to do a given backlog of work. In order to do this, you would need the team's velocity i.e. how much they can do in a given amount of time (usually labelled Sprints and usually 2 weeks) and an estimated backlog of work.

From an estimation POV, the best approach would be to start the work and then give an estimate. Unfortunately most projects do not have this luxury and the PMO will push teams to say how long something will take as early as possible. One of the objectives of grooming sessions is to ensure that the backlog is updated (this includes estimation) and although I prefer regular grooming sessions where we are constantly updating the backlog, sometime we do need to do a 'big-bang' approach and groom all the features for the next release. We all know that the only time an estimate is accurate is when the work ends (so we need to try and balance this process)- however teams do get better at this as the project goes on.

Something similar happens with velocity i.e. at the start of a project, we don't really know what the team can deliver - as the project goes on we get a better idea and plan around this. The problem here is we assume that the same team will remain throughout the project but this is obviously not the case always and this is one of the main reasons for doing capacity planning.

For example, we have done 3 sprints in our project and our velocity is averaging 40 points (team consists of 4 dev, 1 tester and 1 BA) . During the first 3 sprints the team capacity was fairly consistent but in the 4th Sprint, 1 person goes on maternity leave (with no available replacement) and 1 person goes on holiday. In sprint planning we would need to take this into account i.e. rather than committing to 40 points, we would assume 50% capacity for development and plan closer to 20 points (all other things being equal).

Furthermore, in our project plan, if we chose to ignore the new capacity and plan for 40 points (rather than 30 points or less as 1 person is now off the project and cant be replaced), some serious questions would be asked by project stakeholders!

When will Jira support alternative ways of working other than Atlassian Agile?

Like • like this

We have heard this feedback a lot, and is a reason we built a new project type in our Cloud offering.

Scrum and Kanban are great for teams with mature processes and clearly defined roles and responsibilities. But we also realize that not all teams have that all figured out yet.

So we recently created a more flexible, yet powerful, board type to suit the needs of teams who want to create and customize their own unique workflow. The board is entirely configurable, down to things like naming the columns, reordering them, or removing them entirely. If and when you're ready, sprints and backlogs can be turned on in a simple click. The goal here is to let the teams define the workflow that suits their needs best.

I'm in an organization that does daily stand ups, does two week sprints, does sprint planning (tasks) and does a retrospective, but isn't really agile. We deliver in huge batch sizes, we do almost all the requirements and do all the design before we go into sprint, we don't measure and learn.

How do we move towards true agility and customer-centric delivery when a) the team believes it's agile and b) the business is quite siloed into "commercial" who talk to customers and "development" who build stuff.

Like • like this

You're not alone Callum.

It sounds like you're well on your way to agility! You should pat yourself on the back for holding the ceremonies and structuring your development teams as you do.

This is quite a common dilemma, and I see how your org structure impacts your ability to feel truly agile. My hunch is you'd have the most success trying to involve the commercial teams and leaders deeper in your agile process.

Maybe start by adding a demo meeting and inviting commercial team members. You can demo what your team is working on and have the commercial teams act as the "customer" and give feedback. This may help them see how customer feedback is more useful to your team than the requirements they're passing along.

I wouldn't call the teams out as not agile. Once you achieve the next level of agility the agile way of working will show it's value and hopefully it will be recognized.

Hey @Dominic Price!

When it comes to company culture, from your experience how much influence and impact can an individual have in changing or influencing culture? Or is this something that must be defined and modelled by founders / CEO? Asking for a friend ;)

Mikey

Like • like this

Mikey.

I think we can have as much impact as we believe we can have. Cheesy I know, but think about it as having two options. Option 1, you do nothing. It wont improve and you don't learn good habits. Option 2: You do something, and it might improve, and you'll definitely learn something.

I used to suggest that it was the CEO and leaders job, and then someone told me "you know you're a role model for many employees....right?". I remember being shocked, as I didn't have "leader" in my title, but culture isn't the org chart. We're all role models, whatever our position.

y question: what do you see comes after Agile? Is there an evolution of it or a new method on the horizon that you guys are watching so you can keep enabling IT teams?

Like • like this

This is a popular question! I'm going to quote the answer I gave in our top-voted question of the day. Let me know if I didn't quite cover what you are asking!

"For Atlassian, we don't think of changing or deleting anything from the original manifesto, rather we are thinking about what principles we'd add as we apply agile in new contexts like Agile at Scale (taking agile into large and traditional organisations that have different levels of complexity) and Business Agility (adapting agile to non-tech teams)."

We're also really excited about the evolution of IT teams and the different methodologies they're adapting.

Hey Dom! How do you imagine the workplace of the future - say, in 20 years - will look like?

As a futurist, are there technologies or practices you see might play a larger role in an office space?

Like • like this

Would love to see an answer to this :-)

I do love day dreaming about the future workplace and what it might be like. I don't really have any predictions, but there are some trends that fascinate me.

I believe we'll see more companies embracing the power of tech and enabling true remote and distributed teams.
More flexibility in working hours through collaboration tools and the sensible mix of team work and deep work
robots and humans working side by side in an augmented world
humans stopping competing with robots for efficiency, and realising the unique human skills we have around curiosity, empathy and creativity.

Hi Dom, hope you are well.

I'm interested in rolling Agile (Scrum/Kanban) out at Scale and would like to know your thoughts on tooling (Portfolio is still a bit rough around the edges...), which framework you prefer (SaFE, DAD, LeSS etc.) and your approach to getting buy-in across the organisation (management, dev teams etc.)?

Thanks very much!

Like • like this

This is certainly a hot topic on this AMA and at the Agile 2018 conference this week!

Tooling: Portfolio has it's pros and cons, but we think it hits the nail on the head where it counts. It allows you to:

Build a roadmap that's connected to your work in Jira Software.
Get better visibility of work happening across teams and projects
Get an overview of dependencies across teams and projects
Add additional levels of hierarchy above epics.
Get a view on whether your team is above or under capacity in any given sprint.

For pro tips on how to smooth some of Portfolio's edges ;-) in rolling it out across your organization, you may consider engaging with a certified Atlassian Solution Partner.

Framework: As far as frameworks, to me there's no single one size fits all way of working however scaling agile does need some kind of structure, that includes:-

shared ways of engaging other teams
shared and agreed to language
congruence between the behaviours, practices and tools
evolving customization of a framework

My mate Tony Grout, who's done this MILLIONS of times helped me write a little pitch formula to get buy-in. It goes a little something likes this,

"Hey upper manager I've heard you're focused on (pick one of more of the following):

Generating more value
Controlling costs
Engaging the people who work for you so they

There's this thing called being agile, that if done well gets us more value for the same cost or the same value for less cost, helps us manage risk better and we'll also have happier people who produce better quality and save money by us not having to replace them. Can I get 30 minutes in your schedule to tell you how we could start doing this small to see how it can work here?"

Hi @Dominic Price - thanks very much for your reply.

Will have a chat with our local partner at our next AUG - perhaps they can give some examples of Portfolio in action (last time I looked at Portfolio it did have the features you listed but they were not 'complete'). A more visual dependency map (tied to Scrum/Kanban boards) would be most welcome :)

What Scaled Framework does Atlassian use - is it bespoke or do you use one of the industry standards? I have been involved with SaFE and would suggest this works fairly well with organisations already using Scrum.

Thanks for the tips on getting buy-in. I have found that management are happy to use whatever process makes them more money ha..ha.. Seriously most senior management (especially in technology companies) can see the logic behind most of the Agile Principles. When I did my first Waterfall -> Agile project 7 years ago this was definitely a harder sell than it is today - getting metrics from a tool like Jira most certainly helps :)

Hi Brett,

I'm Bree - a PM on Portfolio. Please feel free to send me an email (bdavies@atlassian.com) if you'd like to chat more about Portfolio. Your local AUG is also a great idea.

Thanks for your feedback on improving our dependency visualisation too :)

Cheers,

Bree

What techniques and exercises would you use with each level of and organization to show cultural bias for or against Agile in an organization. How do any of the Team Playbooks connect with measuring willingness to adopt a new work-method?

Like • like this

If you're trying to suss out where agile will be welcomed vs. where in the org it'll be met with resistance, the Health Monitor comes in handy. If folks resist making changes based on what the Health Monitor reveals (or resist a self-reflective exercise like this in general!), agile is going to be a tough sell. It's not a perfect agile-readiness diagnostic, but it's a decent litmus test.

A good way to smooth the path is to try new ways of working that are fairly similar to the way you're working now. Meet folks where they are, score a win or two, then gently tug them further in your direction. For example, instead of weekly status meetings that take an hour, get them to try daily 10-minute standups. Or if a massive retrospective after a project completes is how your org usually operates, suggest mini-retros every other week throughout the next project. (Instructions for both are in the Team Playbook.)

The Playbook also has loads of other techniques and thought exercises that aren't "agile" per se, but help people see the value in trying different ways of working. The DACI play, which gives structure to group decision-making, and the Goals, Signals and Measures play, which is all about project goals, are good starters. They don't feel like you're following a methodology... it just feels like "working smart".

Hi @Dominic Price,

My question has to do with (missing) trust.

We're a division within the IT department of a large company. Our division is the only one working with Agile practices, the rest is still very much in waterfall mode. I am one of the Scrum Masters/Agile Coaches.

We're now 2 years into our Agile transformation that was initiated by the division's management. The teams are doing great and are getting more and more into the Agile mindset, so the Scrum Masters are obviously doing a good job. It has been very tricky to get management properly on board, though. It seems they didn't understand what Agile entails when they initiated this type of work. Their decision-making is a lot of the time not transparent, they have trouble creating a vision for us, a roadmap for the next few years was created without consulting the teams or at least the Product Owners, they don't follow our processes, etc. There is little trust from management towards the teams (sometimes outspoken), but the teams have lost trust in management also (people don't take decisions seriously anymore). The Agile Coaches have created an Agile strategy for the company that would help us build the trust (through enablement and empowerment), but we don't get commitment for this from the whole management team. We continue to try and make the changes bottom-up, but I'm afraid we can't really do much without the whole management team on board.

Do you have any recommendations/ideas on how we can proceed to make things better?

Thank you in advance for your reply.

Greetings from Vienna

Tanja

Like • like this

Greetings from San Diego!

Lack of trust and transparency are all too common, in my experience. It's great to hear your teams are gaining momentum in adopting agile, though!

If I were in your shoes, I'd try to figure out the root case of the lack of trust from upper management (the lack of trust is a driver of the opaqueness so start with trust and you'll solve transparency issues too). Start by asking questions and listening and keep digging until you get at the root cause. Once you figure out what's at the root of management's mistrust, reflect it back to a manager you trust in a productive way, focusing on the potential benefits to them and the organization if these root causes are addressed.

That approach may sound generic, but I hope it helps get you a bit closer to uncovering the source of your management team's mistrust. Keep me posted on how it's going!

What simple methods can a middle manager use to create an agile team?

Like • like this

Hey Laura!

What does an agile team mean to you and what is the problem you're trying to solve?

To quote from a previous question:

"Every organisation is different so there will be many ways for this to succeed. One way is to harness the energy and passion your people already have. Find those most passionate about being more agile and give them all the help you can to make them successful. Then you and they can showcase their success to encourage others to join the movement.

For those appearing resistant, maybe they feel forced to change and meeting them where they are will be more effective. Lose the A word and instead use the practices and behaviours that agile encourages to help solve the challenges they have today, Once this starts to work maybe they'll see the benefit; worst case they'll continue to improve and they'll become more agile regardless.

Also, before you talk frameworks (the solution), make sure to ask questions like "why?" and "what for", so you know the real problem you're solving. "

One of the most important ideas to keep in mind is that Agile is really a set of values and principles - you can start with aligning the team here.

The last thing I'll say - also quoted from a question previously:

"For those appearing resistant, maybe they feel forced to change and meeting them where they are will be more effective. Lose the A word and instead use the practices and behaviours that agile encourages to help solve the challenges they have today, Once this starts to work maybe they'll see the benefit; worst case they'll continue to improve and they'll become more agile regardless."

Comments for this post are closed

Community moderators have prevented the ability to post new comments.

Post a new discussion

Recommended Learning For You

Level up your skills with Atlassian learning

Redesign your workweek

Configure your calendar to prioritize high-impact work and goals. You'll learn how to set daily priorities, prioritize essential meetings, and schedule focus time.

40m Beginner

Free

How to run effective meetings

Lead efficient meetings that have clear goals, keep your attendees actively engaged, and use the Atlassian Playbook to improve meeting success.

30m Beginner

Free

How to build strategic guidance

Build a high-performing, effective team by providing clarity, defining success, and making it clear who will benefit from your efforts — a technique we call strategic guidance.

30m Beginner

Free

Was this helpful?

Thanks!

Teamwork Lab

Forums

Product Q&A

Community resources

Support

Top groups

Community resources

Support

Learn

Community resources

Support

Events

Community resources

Support

Hi! I'm Dom Price, Atlassian's expert on team culture, agile and the future of work. AMA

61 comments

Comments for this post are closed

Comments for this post are closed

Was this helpful?

Thanks!

TAGS

Atlassian Community Events

Forums

Product Q&A

Community resources

Support

Top groups

Community resources

Support

Learn

Community resources

Support

Events

Community resources

Support

Hi! I'm Dom Price, Atlassian's expert on team culture, agile and the future of work. AMA

61 comments

Comments for this post are closed

Comments for this post are closed

Was this helpful?

Thanks!

TAGS

Atlassian Community Events

Welcome to the new Atlassian Community