We have been there. Done that. We lost a few battles and won others. The ones we lost, we could live with.
(I am intentionally leaving out what's already been covered in the other answers and only focusing on the "juicy details", in brief.)
When we were introducing agile to our organisation, they said they understood it, but they completely underestimated the effort it took to actually work that way.
We argued for 25% time of one of the developers on the team who wish to learn about all things process (or had a solid understanding and volunteered). This additional time is the "agile management overhead" i.e., the duties of a Scrum master that can take time away from engineering tasks.
The working agreement that was created by the team was that work items must exist in Jira (which we were using, but product managers were still adapting to it at the time). If something is not in Jira it won't get done and all teams would hold their ground on this.
Managers were notorious for backdoor favors, so making developers as Scrum masters solved that problem since no one wanted to argue with the developers!
The first step was to actually restrict all agile practices at the team level and capture as many metrics as we could regarding the process efficiency. Things like throughput, interruption time, average ticket size, number of bugs being reported, number of last minute tickets, etc. The information produced was eye-opening for senior management (although they didn't believe it).
Some rules of thumb/assumptions that helped start things out:
- Assumed an "ideal day" size of 5-6 hours. That is, the team members should have 5-6 hours of productive time per day with 2 hours for other overheads, lunch, etc. This was the baseline assumption we started with.
- Work was estimated against the "ideal day" benchmark, with a "range". So if something was 1 point, it was assumed to take 5-12 hours of work (1-2 ideal days). Same for other ranges.
- Capacity was simply multiplied by the number of engineers on the team and we would fill up 75% upfront if possible. If we were more efficient, we'd pull in more work; else something would fall off. A five-person team was between (
5*5*10 = 250 to 360 hours)
- Carry over was strictly measured - tasks that we thought we could do but couldn't
- Work was measured; rough start and end times so that we can calibrate if the 5-6 hours assumption was valid. So if something was logged at, say, 25 hours, it implied it was 5 points, and if we estimated it at 2 points we could see errors in estimations and discuss this in retrospectives. The average of all work gave us the ideal day size.
- All measures of backlog size, current burn-down, iteration/release, etc., ticket throughput from backlog to delivery were all captured.
As you can see, these were done by Scrum masters and hence the ask for 20-25% time cutoff from their duties.
Most agilists dislike the notion of "hours"; but since the company had a more traditional management mindset, it was much easier to see hours than abstract "points" which lacked meaning outside the development team.
- The ideal day for each team was actually 3-3.5 hours with a team having only 2 hours! Team members were called in for too many meetings and asked to jump on too many tasks and firefighting.
- Carry over rate was about 20%! There were "live" bug fixes that would fill up about 30-40% of the queue (hence the 75% capacity limit).
- Team throughput was strictly okay around 3-5 ideal days per ticket. The tickets had missing acceptance criteria, or were too big in scope or had missing information
- ...you get the gist.
This allowed us to empower the teams and force others to work with them via an backlog interface to get work done. It was only rolled out to 3-5 teams each with about 3-5 members.
I left the place not long after (for other reasons; one was that they'd actually look to see how many hours were being logged for work items for everyone. Many worked over time and had a huge log and others were compared with that horrible benchmark).
However, the last I heard, the company is "mostly agile" with about 50-60% of the teams adopting it and they slowly tweaking it. However, the initial "metric oriented Scrum tied to hours" was highly beneficial to showcase feedback/efficiency. Something that the higher-ups always seem to value.