Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Dear Therapist, How to work with 'old school' Waterfall method aficionados

Every once in a while, I get to work with folks who are so used to waterfall way of working that they are just outrightly against moving to Agile ways of working,

They want me to configure age old formulas in custom fields, built workflows so complex that Sherlock Holmes is needed to edit them and even after my constant push, wouldn't event want to use the Kanban/Scrum project for their projects to leverage reports, for their so called hardcore "waterfall" projects.


How to deal with those clients, suck up and do what they want, say no to such projects  and move on or pick and choose my battles there..

Any tips from the community is welcome.






Ha, funny, today I was just mentioning my current colleagues one of my previous companies who did exactly that. 

My personal opinion - I'm not sure if it's possible to change that. If they don't truly understand agile and how it works, and you've already explained and talked about it in general, should you really be investing more energy in that? Or accept that waterfalls fits their mentality better?

Like Sajit Nair likes this
Jack Brickey Community Leader Aug 09, 2021

If you can find one or two key flexible leaders within the group and ease them into either an agile approach or a simplified waterfall approach and start there if they get the jest then maybe they can help lead the team in a better direction. There’s nothing inherently wrong with a waterfall approach as long as it’s not overly complex.

Like # people like this

Waterfall has its place and works very well for some types of project.

It's not really a case of "Waterfall vs Jira" - Jira is perfectly capable of being an issue tracker for even the most stubbornly waterfall projects, and actually, Kanban processes and boards can be very useful in them.


>They want me to configure age old formulas in custom fields, built workflows so complex that Sherlock Holmes is needed to edit them and even after my constant push, wouldn't event want to use the Kanban/Scrum project for their projects to leverage reports, for their so called hardcore "waterfall" projects.

I'd point out that the pile of stuff they are asking for is a project in its own right.  Get them to set it up as a project (use waterfall to demonstrate just why it's the wrong approach for software projects - deliver everything as a big-bang in six months time and find out it's not what they actually want any more), and during the design phase question *everything*.  What's the benefit in an 82 step workflow?  What does that add to the reporting?  How does it help developers get on with their actual work?  Rinse, lather and repeat for every field, screen, permission, notification and so-on, and remind them that they have to get it right *now*, because after implementation, it's going to take another 6 month project to make any adjustments.

Like # people like this
Sharon Tan Community Manager Aug 09, 2021

@Sajit Nair This is such a good question, and also reminds me of one posted earlier that's similar. I've worked for an org that was transitioning from waterfall to agile, so +1 on finding champions on teams who see and thinking of ways to illustrate the value can help spread the positive benefits with individuals or teams who want to be more productive or are more receptive to trying a different way of working.

The Atlassian Agile Coach site has a section on the "agile advantage" which might help spur some ideas for facilitating/growing agile interest. There was also a recent blog on bringing an agile mindset to a historically waterfall team and leading by example.

This might go without saying, but you're welcome to get some further ideas or post in our Agile Community group (maybe you could ask for examples of how people have facilitated change over time or illustrated value with certain teams or with smaller projects to gain buy-in and traction). It looks like you're also a part of our Jira Cloud Admin group - it's possible asking other admins on how they've navigated cultural change or compared teams working with different methodologies could provide some insight as well! 🙂

Like # people like this

Nothing bad with waterfall, and nothing bad with agile. Not everything is built to use agile and scrum. Keep in mind that scrum is a framework for complex products in complex environments.

In my opinion, try to act as a scrum master, or as a agile coach, but in the same time you must do what they want, since you are a jira admin.

Like # people like this
nina_schmidt Community Leader Aug 10, 2021

Oh… tough one. All of them have their right to exist…  

i think it‘s all about understanding, hearing them and an open exchange of thoughts 

Like Sajit Nair likes this
Ajay _view26_ Community Leader Aug 11, 2021

Reminds me of the  waterfall Software projects  I used to work on 2 decades ago ...where a typical heartbeat project used to run for 6 months...

I think its best to remind the old schools of the rapid transformation which has taken place (- the lost decade for old schools ) and new ways of working..

Like # people like this

I often anticipate "spirited conversation" when such topics appear.  Awesome!

My perspective/spoiler: there are no best practices, only better ones.  If there was one best way to effectively manage and deliver value we would probably all be using it by now.  :^)

I like the idea of looking at context, having discussion, conducting experiments, and seeking improvement over time by partnering with the people impacted.  And it can't hurt to keep learning to add things to your "toolbox" of ideas and practices.  Trying that is likely to help teams find ways and tools to support them, regardless of what they choose to name their approach.

Like # people like this

@Bill Sheboy - I do like that "there are no best practices" statement. 

I regularly get asked for "best practices" training or implementations from clients.  I don't blame them for asking, it's not a bad way to ask for "tell us how to use the software well, take advantage of what it can do, and avoid doing bad or clunky things with it".

But I always end up explaining that a "best practice" for one place may well not be best for another.  Best practice is subjective and it should be "best practice for us at the moment".    In fact, the only "best practice" I recommend (without a look at how they're working and how they want to), is "continuous evaluation and improvement". 

By all means, let me help you build a system that works for your best practice now, but don't "rest on your laurels".  In a few months after I've left, there's every chance you'll have found new useful reports, changed a process that isn't working as well as you thought it would, started doing new things, stopped doing other things and generally evolved.  Keep looking at that and building/moulding your stuff to match as your "best practice" changes shape.

Like Bill Sheboy likes this


Log in or Sign up to comment

Atlassian Community Events