Atlassian Team 2021 Q+A with Ryan Crow

[#1]

Hello Community members! 

Ryan Crow just gave a talk, Less agile, more agility! The problem with Agile and how to find agility, at Team 2021. 

Agile is a philosophy, yet many enterprises treat it as a set of rules to adhere to. This session explored the "why" behind agile to help teams move from "doing agile" to "being agile." Listeners learned from Ryan how agile philosophy and practices can help your team reduce the time between investment and insights, build a learning culture, empower your team, and create value at scale.

Get your questions in before next Tuesday, May 4th to receive an answer from Ryan. If you don't have a question, feel free to post your #1 takeaway in the comments below. 

[G subramanyam]

Hi @Bridget I would request Ryan Crow to shed light on the below. I keep hearing in the industry about these points:

When we say Agile, they remember Atlassian Agile coach. When speaking of Scrum, they mention oh! the Atlassian Jira is nothing but the Scrum. So, when they speak of Scrum master, they says the role is nothing but managing Jira tool!

What one has to understand is, Agile methodologies holds various frameworks that are sharing common principles and values irrespective of tools we use.

[Crow]

Hi @G subramanyam!  Great points.

Agile methodologies holds various frameworks that are sharing common principles and values irrespective of tools we use.

That's spot-on.  We have to remember that agile methodologies and agile tools are means to an end.  We can go through all of the motions of a methodology and use only agile tools and still not be agile.  As I said in the talk: that's agile in name only (AINO).  The key to agile success is learning to master the mindset and philosophy of agile.  Tools can help us turn that learning into praxis, but they can't take the place of learning -- we've gotta do that ourselves!

I like your callout about Scrum Masters often being pigeon-holed into Jira jockeys because it's a trap I see a lot of AINO companies fall into.  It's a classic cause -> effect mix up.  Often, our backwards AINO approach is: if all our work is in Jira, then we're doing agile.  If the Scrum Master is here to "make us agile," then it's their job to get all the work in Jira.

What are approach should be is: if our team is approaching work with an agile mindset (the "learn -> change -> learn" cycle), then they may be using a flexible tool like Jira that allows them to adapt & iterate.  If the Scrum Master is here to help us learn & grow in our agile practice, then they'll likely be well-versed on what's happening in Jira since that's where much of the team's planning & collaboration are happening.

You know I love analogies, so here's mine for this situation:  if you hire an accountant, it follows that they'll be skilled in using Excel.  But their job isn't to just managing Excel, it's analyzing and understanding your finances. 

If you ask your account about the state of your finances, and they say "I put all the numbers in Excel, so it must be okay," that's the day you start looking for a new accountant!  Worse, imagine if every time someone in your company needed to use a spreadsheet they just said "that's the accountant's job."  No one would get anything done, and your accountant would waste all their time creating workbooks for people instead of helping improve your company's financial situation.

[Christel Gray]

I would love more information about the agile manifesto bookclub. It sounds like a great idea! The only concern I have is my teams have very quiet people, so I worry I'll hear a lot of crickets. Thank you, Ryan!

[Crow]

Hey @Christel Gray, I'm glad the idea appeals to you! 

I've got two suggestions for engaging with the quiet folks...

#1 - Do some asynchronous thought sharing before the meeting

Send the manifesto out as a pre-read, then give the team a space to share their thoughts.  I like to use Trello for this because it's quick and easy to use -- gotta give those quiet people a low barrier to entry for sharing!  You can set up a column for each of sections/pillars in the manifesto, or you could do columns for "like," "dislike," "questioning," etc., or any other structure you think might spark ideas!  Give the team some time to put there ideas on cards, read each other's ideas, add comments to the cards -- they can even vote on them.  

Prior to the meeting, you can read through the cards to get an idea of how to lead the conversation.  Is one card heavily upvoted?  Let's start by talking about that!  Lots of questions?  Work through those with the group.  Something contentious?  Let's find out why.  The cards can also be helpful because you can take notes on them during the meeting to keep the discussion going.  You don't have to close the Trello board after the meeting!

By doing this work ahead of time, you're not starting at square one in the meeting hoping someone will go against their disposition and start a conversation.  You've already laid the groundwork, and the meeting becomes about continuing a discussion rather than starting one.

#2 - Tie the discussion to something specific

Pick something that's at the top of your team's mind -- something you're struggling with as a team, a recent company change, an upcoming project, a looming decision.  Then in the meeting, discuss how that topic connects to the agile manifesto.  Sometimes it can be hard to get people to talk in generalities or about abstract concepts.  By grounding the conversation on something tangible, relatable, and something the team is already passionate about, you can help grease the conversational wheels.

Try to be as specific as you can get with the topic.  Make sure it's something that resonates with the team and is likely to get them talking.  Don't pick something that people are upset about or will make them feel sad or that they're trying to avoid dealing with.  Tackling those problems may come in time, but for this first meeting, you just want to get folks talking and thinking about agile via the manifesto.

To that end, the outcome of the meeting doesn't have to be solving a problem or coming up with a plan.  That might happen, which would be great!  But it might not, and that's okay, too.  Let the conversation evolve naturally, and let the team establish their path forward together.

---

What do you think about those ideas, @Christel Gray?  Do either of them resonate with you?

[Linda Milne_Togetha Group_]

Brilliant presentation @Crow!!! Ive seen far too much AINO.      

[G subramanyam]

Thank you @Crowthat's a brilliant response. Yes, few projects/ companies should understand Agile as-is and it should be the mindset of practicing the values. That analogy is apt and I can quote when needed.

[Christel Gray]

Thank you so much @Crow ! These are great ideas and are sure to help us!