There's one thing that freaks me about agile adoption in large enterprises. WAIT. NO.
There's one thing that particularly freaks me about agile adoption in large enterprises:
Full conviction that it can be done only in a top-down way
It has to be a shift in company's strategy, idea of chairman who had just recently had lunch with someone who's company's doing Agile. And now subordinates politely wait for what their superiors come up with (behind the closed door of their ivory tower, of course):
- what kind of new (& obligatory) tools they will bring
- how will the new development process look alike
- what will be the rules to comply with
- and governence? what how will the governence work?
And BUMMM - yesterday we were RUP, today we're XP or FDD. Screw the obstacles, inmpossible is nothing (yea, that was sarcasm).
It CAN work. Maybe. In a certain sense. To a certain extent. Not that agilish though.
Agile is not a "one & only", single method, it's mindset. There's no prescription, but there's an explicit statement that it should be tailored for the particular purpose. That's why we have Agile Manifesto with WHAT is more important (over) than WHAT. Otherwise we would have Agile 10 Commandments, Agile Delivery Method, Agile Operational Model (or other bullshit).
In other words - people may in the very end use Scrum terminology and / or draw Kanban boards, ...
but ...
- ... do the teams members feel the ownership over the new method / tools? do they feel comfortable with it?
- ... are they convinced that the direction they're heading is a proper one?
- ... is their experience with the products they've been developing (the actual hands-on experience) utilized to tailor the best approach for the organization?
- ... what about the inertia of their previous work - application architecture, planned work, projects in progress, etc.?
The key point is - the bosses are important, but their role isn't really to set up the teams & organize their work, it's much more important:
- to work on so-called buy-in within the organization (executive support, sponsorship, "coverage")
- to help with identifying the correct stakeholders & streamling the communication with them - mainly in terms of setting up a proper Product Ownership in the context of current organization
- to aid the org culture shift that has to happen, if the transformation is to succeed ("one team", sharing the responsibility & accountability, delegating responsibility to operational people)
- to monitor whether teams' work is driven towards adding business value & no-one has been derailed
For the actuam teams - once they grasp the ideas behind Manifesto, it should be up to them:
- how will they adopt Agile values in their specific environment (without disrupting the operations)
- how will they credentialize themselves ("Agile approach means that some things will be missing, but we're going to give you something much better instead") - convince their Business counterparts that they are able to deliver software in the new way
- how will they convince the organization that Agile practices in the area of Quality Assurance are sufficient & won't cripple the overall quality
- what's the "transition roadmap" they can commit themselves to
This is especially important in brownfield environment - where you have a lot of legacy to deal with (both in terms of processes, set-up communications, IT products & services, etc.):
- you may work in 2 week long sprints - SO WHAT if you're release'ing to production thrice a year?
- you may have met your internal DoD - SO WHAT if it still means that additional "regression spring" has to happen before software is delivered to users?
- you're creating Given-When-Then user stories & prioritize them in Backlog, SO WHAT if your business analysts haven't even an opportunity to speak with developers, because they are from off-shore delivery center & their rotation is beyond all recognition
