Marginalizing The Middle
Because they unshackle development teams from heavyweight, risk-averse, plan-drenched, control-obsessed processes promoted by little PWCE Hitlers and they increase the degrees of freedom available to development teams, agile methods and mindsets are clearly appealing to the nerds in the trenches. However, in product domains that require the development of safety-critical, real-time systems composed of custom software AND custom hardware components, the risk of agile failure is much greater than traditional IT system development – from which “agile” was born. Thus, a boatload of questions come to mind and my head starts to hurt when I think of the org-wide social issues associated with attempting to apply agile methods in this foreign context:
Will the Quality Assurance and Configuration Management specialty groups, whose whole identity is invested in approving a myriad of documents through complicated submittal protocols and policing compliance to existing heavyweight policies/processes/procedures become fearful obstructionists because of their reduced importance?
Will penny-watching, untrusting executives who are used to scrutinizing planned-vs-actual schedules and costs in massive Microsoft Project and Excel files via EVM (Earned Value Management) feel a loss of importance and control?
Will rigorously trained, PMI-indoctrinated project managers feel marginalized by new, radically different roles like “Scrum Master“?
Note: I have not read the oxymoronic-titled “Integrating CMMI and Agile Development” book yet. If anyone has, does it address these ever so important, deep seated, social issues? Besides successes, does it present any case studies in failure?
… there is nothing more difficult to carry out, nor more doubtful of success, nor more dangerous to handle, than to initiate a new order of things. For the reformer makes enemies of all those who profit by the old order, and only lukewarm defenders in all those who would profit by the new order… – Niccolo Machiavelli
Leave a Reply
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 
Agile switchover has gone from a trickle to a flood in banking IT. However, it is also used in mobile phone firmware and software projects by that Finnish mobile giant, proving that hardware dependencies are not an impediment to going Agile. Mission, safety critical sectors also use it. After all, decades of waterfall top down projects in IT shows mixed results at best.
Instead of ‘why Agile’, the question has changed to ‘why Waterfall?’ when a project methodology is being contested. Executive management like the concept of rolling releases. And Product Owner has numerous opportunities to ‘inspect and adapt’ across the iterations of a release, in the sprint showcase and in the sprint planning and retrospectives. Results in a final product much more likely to meets business expectation from the outset. PMs are reinventing themselves as Scrum masters. This has it’s challenges, but many do make the transition. Good news is that technical leads also get a chance at this role, and in fact QA, BA practitioners too, whereas there was more of a career demarcation between manager and non manager roles when on warterfall.
Thanks for stopping by and weighing in Parvez. But, where’s your evidence? Sorry, but “it’s just the way it is” doesn’t wash with me. What about the agile adoption failures? Tell me about them. What is the ratio of successes to failures? As Scott Ambler has said: “Everybody’s doing agile these days, even those who aren’t”. 🙂
Fair point, I have heard of Agile adoption problems. In fact, it would be more surprising if an organisation steeped in a diametrically opposite methodology and values, was able to smoothly switch over, all things being equal with same people, testing and build tools, and job roles, and succeed from the outset.
But the critical saving grace of Agile when failure is rearing it’s head, is that failure is ‘fast and early’ . i.e revealed within a sprint, during the ‘showcase’ (so 2 weeks wasted effort typically), with plenty of opportunity therefore for feedback and equal, open, no blame discussion to steer the project back on track. In waterfall, however, the first a user may realise his needs have been misinterpreted could be at the UAT phase, by which time several months or more have elapsed since initiation. Then the blame game begins on whether it was the BA, QA or developers that got it wrong!
In short, job roles in IT and attributes traditionally associated with each them, are getting turned on their head! Instead of a PM who does little more than get status updates and track progress, as a Scrum Master you need someone who can facilitate who ‘gets’ the strengths and tools of the team (developers, QA, BA) at hand, and allows them to self-organise to deliver the goal of a 2 to 4 week sprint.
The links below give examples of real-world agile adoption experiences at 2 different banks, and they are interesting as these both used to apply highly controlled, monolithic project methods.
http://www.itnews.com.au/News/260642,nab-dumps-steering-committees-for-agile-projects.aspx
http://www.itwire.com/business-it-news/technology/56021-jp-morgan-claims-agile-advantage
Well said, and you’ll get no argument from me Parvez. I’m no plan-everything-down-to-the-last-hour-and-penny waterfall fan. That approach actively invites failure into the scene for those on the receiving end of “the Gospel plan”. I think agile processes, done right, will blow plan-heavy processes out of the water on all three corners of the iron triangle. It just seems like a much bigger, riskier challenge for the aerospace & defense industry to successfully morph into an agile society than the business IT industry.
Thanks for the links!
I prefer penny-pinching to penny-watching. It seems more traditional.
Fair enough. Thanks for listening and commenting.