For a long time it's been "big data". Now comes the new coinage: "big Agile", or agile on a really big scale
It's all about scaling up. The argument, if there is an argument, is about whether to (a) add more process to handle more scale -- which is somewhat like saying add a framework which itself is often a surrogate for guided workflow processes -- or (b) just add more smart teams, pump up the collaboration so that everyone is doing 360's with everyone else, and apply a touch of process to tie them together. That's the recipe, or so we are told.
In reading stuff on this topic, I was struck by this bit of wit:
Simple, clear purpose and principles give rise to complex and intelligent behaviour. Complex rules and regulations give rise to simple and stupid behavior.
What more do you need? We have the Agile Principles; we have some methodology guidance (Scrum, XP, DSD, etc), so we've got it; that's all smart people should need.
I actually agree with CEO Hock on the big picture (said picture to go along with the other biggies: data, and now Agile): a light touch in governance is likely better than Taylorism: all jobs scripted and defined to a fare thee well. Why so? Simply for the point made by Hock: advantageous behavior arises where there is flexibility to be different and challenging.
But, let me put in a word for process, especially as required in "big Agile". If by big Agile you mean a half dozen teams, then perhaps you can get away with a pretty simple guidance paradigm: do no harm to the other guys, and check in regularly.
But if you are talking seriously "big Agile" with many distributed teams, lots of interactions and dependencies on a myriad of non-development stuff, like training and logistics, then it's not good enough to just have the "dots". There has to be a systemic and sustainable way to connect the dots, and that's what's embedded in process.
Try building a million lines of code contained within thousands of objects for an automobile, to take a relevant example, without some serious processes for handling interfaces, integration testing, validation of function and feature, and customer supportability, to say nothing of reliability, security, fail safe, etc (Remember the Toyota thing with the unintended acceleration? Was it the software?)
Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
Read my contribution to the Flashblog
