What if you have 9 scrum teams trying to implement a piece of software. To make things challenging, the scrum teams are supposed to work on components that are interrelated and depends on each other. Imagine scrum team A's component needs a service from a component still under development by team B? Now of course team A can just wait until team B finish their component and just sip coffee and write tech. blogs (like this one) all day long. But I'm sure the business types would be pulling their hair out (and note that they don't have that much to pull out anyway) when they hear that. Heck, they might even force you to use *gulp* CMMI processes from now on.
Another option is for team A to mock the team B's component and go to work with that. That is a better solution but here's the kicker, what do you mock?
The answer is team A and B need to sit down and properly design the boundry and contract of their components up front so that work can be done properly and team A does not need to bother team B every 3 days because they need a new service. Things could be worse if team A and B are located halfway across the world working in different time zone and whatnot.
But you see, I'm shivering here while typing this because "sit down and properly design the boundry and contract of their components up front" does not sound "agile".
Somehow, there is this meme that has been going around saying,
anything up front != agile
Bullsh*t
There are to ways of looking at this:
1) If it's not agile, who cares! I just need to get my work done! If it's not agile. I don't give a rat's *toot*
2) Agile is about easily making changes and not about "being lazy". You can design "enough" up front without making your system brittle and crack under load of changes, can't you? Sure you can. The only reason that you do not want to do it is the plain old sin of sloth. Not the agile philosophy.
It's is bad enough that when the agile movement started, some developers embraced it because they were just lazy to think through what they do and just wanted to code. And thus this meme where agile is seen as a holy war againts anything upfront, even planning, sometimes, was born. Oh we don't plan, we're agile. Bullsh*t!
Could the upfront stuff change? sure, that is what agile is all about. But team A and B might need to sit down together again maybe once in the next 2 months. But if things are not defined up front, you may have to poke that nasty evil-eyed team lead from team B for his help every 3 days. Do you really want to do that? *Now please voluntarily imagine his evil-eye... yup, not pleasing isn't it*
Things could get worse when A depends on B, B depends on C and C depends on A. This circular dependency is sooo going to kill your project if not managed properly.
So, as a conclusion: agile is good, being lazy, whatever excuse you tag it with is just evil.
Another option is for team A to mock the team B's component and go to work with that. That is a better solution but here's the kicker, what do you mock?
The answer is team A and B need to sit down and properly design the boundry and contract of their components up front so that work can be done properly and team A does not need to bother team B every 3 days because they need a new service. Things could be worse if team A and B are located halfway across the world working in different time zone and whatnot.
But you see, I'm shivering here while typing this because "sit down and properly design the boundry and contract of their components up front" does not sound "agile".
Somehow, there is this meme that has been going around saying,
anything up front != agile
Bullsh*t
There are to ways of looking at this:
1) If it's not agile, who cares! I just need to get my work done! If it's not agile. I don't give a rat's *toot*
2) Agile is about easily making changes and not about "being lazy". You can design "enough" up front without making your system brittle and crack under load of changes, can't you? Sure you can. The only reason that you do not want to do it is the plain old sin of sloth. Not the agile philosophy.
It's is bad enough that when the agile movement started, some developers embraced it because they were just lazy to think through what they do and just wanted to code. And thus this meme where agile is seen as a holy war againts anything upfront, even planning, sometimes, was born. Oh we don't plan, we're agile. Bullsh*t!
Could the upfront stuff change? sure, that is what agile is all about. But team A and B might need to sit down together again maybe once in the next 2 months. But if things are not defined up front, you may have to poke that nasty evil-eyed team lead from team B for his help every 3 days. Do you really want to do that? *Now please voluntarily imagine his evil-eye... yup, not pleasing isn't it*
Things could get worse when A depends on B, B depends on C and C depends on A. This circular dependency is sooo going to kill your project if not managed properly.
So, as a conclusion: agile is good, being lazy, whatever excuse you tag it with is just evil.
1 comment:
There will always be lazy people (not referring to anyone in particular), and they particularly abuse such words.
What you professed at least to me falls more into the category of documentation. Just that i suspect you are not going to say that hated doc word cos it is a hated word by lazy people.
So Agile is a used escape hatch, so just watch out and test them with the doc word.
Post a Comment