nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Miscellaneous Monday - USE THE FORCE, LUKE

Meg Holbrook

Happy Monday Morning Everyone!

I know that Miscellaneous Monday threads are typically not work-related, but I was reading an article on LinkedIn today called "That's Not Agile..." and I wanted to talk about it with you a little today.

The TL:DR version goes a bit like this:

Teams engaging in Agile methodology have the potential to be pulled out of the framework by teams or people that are not. This leads to heaps of frustration on both sides because the people requesting the "non-agile" changes know you can do the work, and are puzzled as to why you can't/won't pivot. The people on Team Agile, on the other hand, will shout from the rooftops that there is a process and it is to be followed.

The article goes on to address some alternative responses, which could be likened to the old 'you'll catch more flies with honey than vinegar' adage. All of this seems to point to the fact that as well as being subject-matter experts and code wizards, the next step in our evolution should be developing mad Jedi mind tricks.

The most-impactful statement of the article is here:

At the root of it, it's not about saying, "that's not Agile." Each part of the process we follow has a purpose and an impact, and so we must find a way to express the real challenge, impact, or risk in another way

The biggest hurdle for me as a Jira administrator and agile-proponent is that folks on the other side of the window just don't know what sprints, backlog, scope creep, scrum, and prioritization are. We're not starting with common language. Unless we change the way that we're communicating these hurdles, in a non-hostile manner, we'll constantly be fighting fires and battling over semantics.

It's clear that our communication should be focusing more on the outcomes and pulling away from radical agility (should I trademark this?) , which is largely easier said than done when you're in the thick of it.

What I want to know today is, have you fallen to the dark side in an endless downward slide of pivot/firefighting? OR do you use your powers for good and gently explain the benefits of agile process and stick to your guns... er... lightsaber?

Comments

miikhy

Hey Meg!

What an interesting question.. I've also found that educating people to Agile values and their meaning, the reason they were thought this way helped. That being said, sometimes people are just not open to it (let's not make a link with the average age of population here haha). The most important is always to get support from key people.. whether it's management or team members, whenever I can feel the global mood of a team, I'm more able to help and explain to people. Sometimes I also just drop it as people/projects are not ready for it and transition would cost too much!

My secret weapon? Beside being Atlassian Certified I'm Agile (Scrum) certified and use that as a fact to strengthen my speech: "I can see the end to end benefits and will be happy to try and convince you", but pushing too hard is not a good idea

Excited to read more tips!

Meg Holbrook

@miikhy I agree that having certifications is a big help, and also that some people just will not be persuaded.

I think the Agile superpower is in that flexibility if we can 'let go' of the need to always have firm control. At least, if you can keep from spinning out of control.

Let-it-go-memes16

miikhy

True!

Like the Elsa reference! Will remember it next time I have to support an Agile transition

Jack Brickey

Hi @Meg Holbrook and thanks for sharing the article and synopsis. I think many of us, if not all, have found ourselves in similar situations and in fact I have been on both sides. I have evolved my agile thinking into an understanding that being agile doesn't mean being inflexible but it does involve focus and control.

I often have found the following thought bullets useful when working w/ someone that is trying to have my agile team pivot. My goal is to focus on a common problem that both sides have (meeting commitments) and make that the enemy that we can both get behind.

Meeting development commitments is important if not critical.
Churn in development is inevitable and is often necessary to deal w/ changing situations.
Incremental commitments (sprints) are easier to manage and provide a means of managing churn. 'You don't need to wait for the next large requirements cycle to slip your request in, just wait a couple weeks or less.'

I then direct the attention to the current backlog and discuss where the request should fall in the list. If It is at the very top and we are weeks away from completing the current sprint then we begin to discuss the tradeoffs of disrupting the active sprint. vs. waiting.

So in the end I guess I tend to try to work collaboratively as much as possible. I try to get us on the same side. Ultimately the product manager needs to weigh in on any pivot that results in impacts.

Meg Holbrook

@Jack Brickey - I love the idea of 'uniting against a common enemy'. That really re-frames the conversation from an us vs. them mentality towards the 'all for one'.

I very much agree with empowering the requesting people to fit their projects into the backlog. I think people tend to have a very pinhole view of what they need and how urgent that request is and giving visibility into organizational goals really helps them to understand that there may be even greater priorities.

unknown

Curious to know how certifications are helping? Does it help you convince non-agilist's that Scrum is a proven method? Or does it give you more arguments from the training to convince people over?

unknown

My direction would be:

Being open and transparent

Let people understand the current priorities of your team and try to understand the priorities of the requests. Pure agility is not talking about sprints or time boxes. It's about being adaptable.

I also know from experience that there always the same people are coming to my desk requesting something reeeaaaaly important. I think bringing that up to a broader group of stakeholder and discuss priorities or having a Confluence page with all projects in the queue listing customer value (short term and long term) and organizational helps other people understand your roadmap.

I think it all comes down to understanding of priorities on both sides.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

agile

off-topic

miscellaneous-monday