I don’t think the principles are far off but a rewrite could be a good thing. It’s a bit much to go into from an iPad on the couch though.

I’m currently reading a book on Disciplined Agile Delivery which is quite interesting from considering the parts of game dev that I always struggled to square into a pure Scrum methodology.

Thanks for the responses everyone. I’m going to try to more comprehensively explain my position in a series of upcoming posts. The main point of disagreement here is that people seem to think that there’s something not intrinsically bound between Agile and programming; I wholeheartedly disagree. I’ll start by explaining how Agile in general, and Scrum in particular, doesn’t apply to art production (I notice a number of people mention Art in the comments). I’ll use that to revisit my thesis here that understanding Agile requires a programming background, and give some more rationale behind certain points.

As a project manager or a program manager I need to help teams to deliver stuff – and I need to ask the team how to do that in the best way. And I will do mistakes and learn. But I do not need to be a programmer to do the right decisions. I’ve probably seen as many managers with a programming background not being helpful for teams trying to work in an agile way as managers without this background.

I would also say: you need to experience working in an agile way – but this is possible for people with or without programming background.

To me, the behaviour you’re describing has nothing to do with a PM not knowing how to program, but it’s someone who doesn’t know how to respect people. So when confronted with such behaviour the problem is not to learn the PM how to code, but learn him to respect craftsmanship of any kind.
And the Agile Manifesto doesn’t have much to do with developing to me too: it’s about giving professionals some space to create value with a team. That what the writers united, was the need for air for any kind of professional working on something cool :)

But understanding agile is more than understandig how to be an agile programmer – so I believe that you can truly understand agile without beeing a programmer or even have knowledge of programming. what about all the information architects, the designers, the leaders coming from other departments.

working in an agile way is not limited to programmers. the ideas of delivering fast and early, of prioritization, of not building all but the most important first, of Individuals and interactions over processes and tools, of Customer collaboration over contract negotiation, Responding to change over following a plan and even of Working software over comprehensive documentation is not limited to the league of programmers…

Robert Kist: I think you touch directly on the problem. Things like Scrum have no business being applied to art production, yet because the people responsible for Agile implementation have no real ability to truly understand what makes Agile work, we end up with art teams working in 2 week sprints. I just don’t believe Agile is something you can merely read about to deeply understand; you have to experience it. And without deep understanding you have no business deciding how it should work.

Rob S: That’s side-stepping the issue. Someone outside of the team needs to decide that teams are actually autonomous, that people outside of the team don’t have control over how the team works. Can the person who makes that decision, and similar project-wide decisions about the preconditions for how teams work, understand what decisions they are supposed to make if they don’t have a programming background?

A good manager should be able to as Rob Schluter said, remove obstacles and support the team with a solid understanding of the company, project goals and the team members and be able to balance that and enable to team to do what they are best at.

The better a manager can listen and understand and communicate with people the better manager they will be. The problem is that in games from what I have experienced, people that are really good at doing their job are removed from that role and told to be managers with out much in the way of grooming, training or even finding out if they even want to manage. The view of ” you have the most experience,stop and now do a totally new job that has little to do with what you are best at” is a terrible model. Yet it happens and then it is always a “surprise” when a project goes of the tracks.

The flip side to this is , lets bring in someone from the outside – late, give them no time to ramp up and understand the company culture, expect them to work magic on a project and then scape goat them when something goes wrong because of unrealistic expectations and support…overtime will fix it, churn, burn, layoff, repeat until by accident something is successful and then they have no idea how or why and can’t repeat it- churn, burn, layoff, on the next project.

Your main question to me is ” So should he be responsible for the implementation of Agile?” , no – it is the entire company and teams responsibility to implement agile and then put someone in a role to run it that understands how the process works, the need and want to do better has to come from inside the company culture and then be backed up with action.

Right now game development project management looks like someone on a series of crash fad diets with no idea of basic nutrition and then wonders why they never lose weight or get more fit, thinking that there is one new “management” shake that will fix everything.

So as soon as an agile team has been formed a program manager has handed over the responsibility and is no longer the one to make decisions about how that team works.

Only if the program manager joins a team (s)he can join in the decision making process. But with that role change also comes a change in activities.