Is there a hybrid approach that can keep both parties happy?

[Chris Guyette]

Our management team hasn't bought into scrum, and prefers waterfall (detailed upfront specs, gannt, schedules, dependencies, etc), but our development team prefers scrum which generally works with concept of sprint. Is there a hybrid approach that can keep both parties happy?

[Junilu Lacar]

Just to give you some idea of where I'm coming from, my current day job is as an Agile Transformation coach and previously I was a tech lead and Agile champion on my team. From my experience, almost all agile adoption efforts are "hybrid". People tend to adopt the practices they like or feel fits better with the way they currently do things.  This is a practical approach because as with many other things, a sudden complete change is usually too disruptive and seldom successful.  Organizations have way too much momentum and too much riding on how things are currently done, no matter how much pain it is causing them.

A move to more agile processes and techniques, both from the technical and management sides, is best done incrementally, with lots of failing and learning along the way. Some organizations expect to get it right the first time, which is ironically antithetical to the the principles and values of Agile Software Development. As far as I know, there is nobody who has transitioned from waterfall to something different like Agile who has not had to deal with the challenges of introducing change. Resistance, lack of understanding/education/socialization, misunderstanding, lack of coordination, and many others contribute to the pain of change. Your success in transitioning to Agile depends your organization's ability as well as each person in the organization's ability to deal with and address those pains.

There are many ways these transitions can happen but there is no way it can be sustained without management support. Grassroots efforts to go agile, even ones that can demonstrate significant improvements, can quickly go south when ill-informed and/or misguided management tries to get into the picture.

Management should be concerned with achieving business goals, not dictating how developers do their work. On the other hand, developers should understand what management really wants and why they think a waterfall process helps them get it. If I could give a free word of advice, it would be to have a dialog with management. Ask them what their goals are for the business and tell them why you feel that Scrum would help your team help them achieve their goals more effectively than if they imposed a different development process on the team.

[Mano Ag]

Hello Chris,

Yes the hybrid approach is possible, and it will have its special flavour on a case by case basis.

In our case we were able to transition to Agile (in the shape of Scrum) and still be assessed at
CMMI Level 3 in which I think is a good example of what level of adaptability can be achieved.

[Tim Holloway]

Junilu Lacar wrote:Some organizations expect to get it right the first time

But seriously, one of the foundations of Agile is flexibility. It wouldn't hurt to point out that the biggest problem with waterfall is that everybody wants everything yesterday and Agile is, in large part, dedicated to the idea that getting something soon will make them happier than waiting forever for the whole package. And if you can make that something look sufficiently like a waterfall, so much the better. But getting the recalcitrant manager to help shape the process (as opposed to outright dictating it) is the key.

I think a lot of the appeal of Waterfall is that once you go into production, it's "Done".

Except that it isn't. Certainly 30 years of updated versions of Microsoft Windows and Office should give some clue to that. And in case someone says that's just marketing, there's also Patch Tuesday. You cannot pay for software once, get a fixed product and forget it. Software, as I've said before, rots from the outside in. Even in the unlikely event that business needs don't change, the hardware, OS, and general runtime environment will, and if you just push stuff on the shelf because it's "Done", sooner or later it's going to resemble what you pushed in the back of the refrigerator.

[Junilu Lacar]

Tim Holloway wrote:...the biggest problem with waterfall is that everybody wants everything yesterday

That doesn't change with Agile although in my opinion, Agile techniques give you more tools to not only negotiate just how much they'll get and when but also the ability to deliver the things that are of most value sooner rather than later.

[Tim Holloway]

Junilu Lacar wrote:

Tim Holloway wrote:...the biggest problem with waterfall is that everybody wants everything yesterday

That doesn't change with Agile although in my opinion, Agile techniques give you more tools to not only negotiate just how much they'll get and when but also the ability to deliver the things that are of most value sooner rather than later.

Yeah, that was the point. The difference is in how long you tell they've got to wait.

[Jeanne Boyarsky]

Crhis,
Remember that you can do some agile/xp practices on a waterfall project. Nobody is stopping you from doing retrospectives or pair programming for example. And neither requires management permission. The work is still getting done.

[Junilu Lacar]

Jeanne Boyarsky wrote:And neither requires management permission.

I wish that were absolutely true. If management doesn't normally stick their pointy-haired heads into development's business, that's great. If they do, I've mostly gone with asking for forgiveness later. Honestly, I hardly ever ask for forgiveness for doing my job well so I just help management understand what the benefits are for letting me do my work the best way I think I would do it.  

[Jeanne Boyarsky]

Retrospectives - "Oh, so we aren't allowed to talk to each other"

Pair programming - "Both individual tasks got done on time/in the same schedule."

[Junilu Lacar]

I get the one about PP but I can't even begin to imagine what the thought process was like with the one about retros. What's the backstory on that one?

[Jeanne Boyarsky]

Junilu Lacar wrote:I get the one about PP but I can't even begin to imagine what the thought process was like with the one about retros. What's the backstory on that one?

I haven't needed to use it, but that would have been by defense years ago. (Now management embraces Scrum.)

We did retrospectives on a very waterfall project. I never asked for permission to hold retrospectives. If challenged, I was going to ask what the rule was on teammates talking to each other. An impromptu meeting vs a scheduled meeting take the same amount of time. If it is ok to have a full team design meeting, it becomes hard to say you can't hold a retro.

[Junilu Lacar]

Thanks, Jeanne. I get it now. I read those with a different context in mind, hence my confusion.

[Jan de Boer]

Of course you can, becáuse there is no real waterfall vs agile antipole. In fact that whole antipole is an invention of agilists. There are a set of tools you can use, and that has been used before somebody wrote down the sacral manifest. Things like automated testing, code reviews were done long before some people start putting the agile tag on it. The same goes for retrospective. Do you think coworkers never sat together discussing how they could do things better before agile? And yes, pair programming, of course in the 'waterfall days' it was prohibited to ask a coworker to look at your code and to try to find out the solution of that pesky problem together. Duh, not really. I would even say that if you are not practicing these things, you are not practicing good software development, even in ‘waterfall’, whatever that actually may be..

[Jan de Boer]

Jeanne Boyarsky wrote:We did retrospectives on a very waterfall project.

This is relevant. I personally think this whole waterfall/agile thing is not all this black and white. Otherwise I would probably even go mad in this agile environment, where some people just take agile too seriously. E.g., when they built the Notre Dame in Paris, in the 13th century, I am sure the workers also looked backed on the work done and shared knowledge how to improve it. Or even in prehistoric times when a group of agile hunters tried to chase down a mammoth, they held retrospectives. It is not like since somebody wrote the agile manifesto, people tried to regularly look back on a project and investigated how to do things better. If that were literally the case, we would still be haunting mammoths.

Could be a good thing though, it might have saved the mammoths from extension!