Agile isn't easy

I'm sure other people tranistioning to agile have had this thought. Isn't agile supposed to make my job easier? Won't I have more time to golf and relax? And yet, agile seems to be harder, and require more work and effort, than doing things business as usual. Well, guess what? Executing great work at the highest level is hard! It's harder than business as usual. But it pays dividends. You delight your customers, you have a happy, satisfied team doing valuable work.

The moment the team stops doing work against stories its committed to, the magic leaves the room, quickly and dramatically. This is your fault as the product owner or business manager, not the teams. Business inputs will constantly distract you, customers will constantly derail you, personal issues will manifest in your team's lives. The world will never cease in its efforts to derail, and that's why you have the hardest job of all as the product owner. You're the glue holding the whole thing together, keeping the world at bay.

It actually reminds me a lot of skeet shooting. Shotguns are weird weapons, and skeet shooting is quite the challenge: you're trying to hit a moving target with an explosive burst of shot. You're not sitting there at the range, lying prone, taking as much time as you need to put the bead on the bullseye. You've got at most 2-3 seconds where the clay will be close enough to the target area where your shot will hit it with any force.

The magic of the shotgun is that you don't aim down a site. You line up your vision to the sites - you put your entire upper body and vision in alignment so that you can follow the target with your eye. You no longer aim. You see the target line up, you squeeze the trigger, and pow! it explodes.

This reminds me a lot of setting the goals for a sprint. It's all mental. You have to line everything up to hit the target before shouting "pull!" and if you don't, you're guaranteed not to hit this elusive target. Go down to your local clay shooting range and try it out, you'll find it weirdly identical to leading a software team. Take your whole team as a team-building excercise. There's something interesting that happens when you fire deadly weapons together safely.

Scrum requires course correction at every turn

Scrum is a process of correction. You don't just start doing it and then everything just magically works. The first Sprint will have failures, processes that didn't work, procedure that wasn't followed, ideas that didn't sink in. At the end of the Sprint you review and course correct. Individuals on the team constantly strive to hold up their end of the Scrum contract, while the whole teams looks for ways to change, adapt, evolve, and innovate. It's just like sailing, there's constant course correction that goes from coarse to fine as you get closer to port.

Scrum requires teams

In order for teams to manage themselves, they need to be dependent on one another for direction. They can not look to the ScrumMaster or Product Owner for direction or orders. The team uses its abilities ranging from subject matter expertise to best gut instincts to make its own decisions. It is very much like a sports team where everybody has a role, but the team wins games as a team, not as individuals. In Hockey, you get the same amount of points for an assist as you do for scoring a goal and it is the same in work.

The reason Scrum and stand-ups never worked at my old job was because "team" members were pitted against one another. It was a Lord of the Flies, survival of the fittest, where progress was always reported to some kind of boss man. No one in the group ever had a stake in the success or failure of the work other team members were doing. It was much more like a World Rally Cross event, where team members all drove Subarus but were conducting their own race, competing with each other to win each stage of the rally. It was awful.