Heads up! On March 5, starting at 4:30 PM Central Time, our community will be undergoing scheduled maintenance for a few hours. During this time, you might find the site temporarily inaccessible. Thanks for your patience. Read more.
×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?
Community moderators have prevented the ability to post new comments.
@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.
True!
Like the Elsa reference! Will remember it next time I have to support an Agile transition :D
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?
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.
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.
@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.
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.
Community moderators have prevented the ability to post new comments.