I used to do agile transformation via a consulting firm and now run the agile delivery org (20+ SMs) at a company in the city.
Scrum itself is relatively straightforward. It's only about 19 pages and basically speaks to the key attributes of scrum: ceremonies, roles, and artifacts.
3 roles: Scrum Master, Product Owner, Team Member
Ceremonies: Daily Stand-up, Sprint Review, Sprint Retrospective, Product Backlog Refinement, Sprint
Artifacts: Product Increment, Product Backlog, Sprint Backlog (I'd add a risk or impediments log here too)
Typically, work is broken down into 2-4 week increments called sprints and a small (5-9 people) cross functional team delivers within that time box.
Soapbox moment: If an organization is talking about digital transformation and agile, they likely don't realize the scope of change they're talking about and believe that adopting scrum as a "project management" methodology will deliver better outcomes. 19 pages of framework which basically assumes high performing, "t-skilled" team members with intentional proximity to the actual problems flies in the face of a century of Taylorism and specialization.
To your larger question about scale, scrum does tend to require deliberate co-ordination when there is work that can't be completed entirely within the cross functional team (think specialized skills like ERP, mainframes, etc.) or if it is a larger program and the scrum teams likely start to reflect different features (feature teams) within the larger program.
PMI acquired Disciplined Agile last year so they are likely growing their certifications beyond the PMI-ACP into the DAD space.
From a tooling perspective, JIRA is definitely out in the wild with likely the largest market share but there are tons of tools out there like VersionOne, Rally, LeanKit, Kanbanize.
Happy to share more if there's any more detail you want to get into. I've run a couple of large scale agile programs so I'm full of war wounds on successes and failures.
|