Tuesday, September 15, 2015

Escalation?

Normally an agile team takes responsibility for getting things done into their own hands. In the best case its a DevOps scenario and you have embedded folks who have all the skills and access required to tackle the non-code issues that will arise in a project/product/program.

If the database is down the DB folks will log in, make the required changes, script the fix for higher environments and roll it along.

If the server has issues the Linux dorks will login, clean things up, script it for other environments and rinse and repeat.

But what do you do when you are an agile bubble in a waterfall world?

That is when things get more difficult. Assuming you have the ability to even access the DB or the server odds are quite good that you won't have the correct permissions. More likely you can't even get in. In this scenario you are dependent on an external team. Who may have other priorities. And be matrixed across many projects. And they don't understand your urgency. After all, its just a Dev server, right?

Well now it sucks. You can call/email/IM them about the problem. Better yet you can walk down and discuss it. They maybe even take care of the issue for you.

Hurray! Back in business.

Until the problem happens again. And again. And again. I'm not loving this game.

See the thing is that they are clearing the immediate problem but not addressing the longer term issue. So it keeps happening. And you keep talking to them and they keep quick fixing and blah, blah, blah. 

I understand. Their priorities are different and I am not the primary responsibility. But after a few trips down you would think we'd all be tired of this game and the problem would have a long term fix. Does it sound like the 90s all over again. Of course not because back then we wouldn't even know about the issue until three months later when everything is due and we are manually jamming it into prod.

Ah the good ole days....

Anyway, how do we, being agile, deal with a problem that can only be fixed by a waterfall person? Well, we discuss it with the folks down there (up there, wherever) and explain the longer term problem. When that doesn't work we need to start escalating.

That means the scrummaster and the PO get notified. Scrummasters remove impediments and POs want there stuff done so they can raise it to whomever they need to. So now we are pushing things up the org chart so it can come back down the other lane in the org chart so that a fix can get implemented.

The thing is that there doesn't appear to be a better solution. We need paper trails and risk statements and some potentially bruised egos just to get what seems to be a logical solution to a recurring problem where two different groups work in completely different models.

No one said things would be easy. But when you are banging into waterfall there aren't many other solutions. 

DevOps would be nice. But that isn't always possible and then we are left with some old world tricks.

1 comment:

  1. Sometimes I've gone as far as to spin up a complete simulated stack of everything else I need, while DevOps/DB/whomever are doing the "real" fix. At least that way I can keep working. And sometimes other teams see that, and realize "hey, we don't HAVE to be stuck in the interim". YMMV.

    ReplyDelete