Can't we all just get along?

Lean, Agile, Scrum, Kanban.

They are all approaches/methodologies for doing what we all agree is important for our industry to move forward to a more effective approach to getting our products done faster and with more quality and value.


That being said, why do we in the community keep attacking and denigrating each other's practices for achieving these goals? Are we really so petty? We are all working to the same goal. We want to build good software. We want to use tools that help us to get it done. We want the minimum interference to completing our work.

TDD is good, TDD is bad. ATDD works, ATDD doesn't work. You need to do Scrum, no you need to use Kanban.

Let's face it, these are all tools in the toolkit and not all tools are needed all the time. You pick and choose what is needed for the particular task at hand.

Quit maligning each other.

Agile has become a mainstream buzzword and once things become mainstream they are inherently more visible. The ideas underlying the original definition of the Agile Manifesto is getting lost in all the religious wars. As such, we are allowing ourselves to get sidetracked from doing the job right. And by right I mean with business value, high quality, maintainable, with an ability to plan for the future without overbuilding.



- JMH

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.