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

[#1]

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.

Cheers-

SN

[Anita Kalmane]

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?

[Jack Brickey]

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.

[Nic Brough -Adaptavist-]

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.

But:

>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.

[Sharon Tan]

@Sajit Nair _Trundl_ 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! 🙂

[Mark Jestings]

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.

[nina_schmidt]

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 

[Ajay _view26_]

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..

[Bill Sheboy]

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.

[Nic Brough -Adaptavist-]

@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.