Can you grok Agile without a programming background?
The last fourteen years have been strange. The Agile movement, which was spawned out of the controversy over Extreme Programming, skyrocketed into success, and was subsequently taken over by the project managers who all but pushed the programmers out. We’ve seen the creation, the wild success, and the corresponding (and predictable) impotence, of certifications… We’ve experienced continuous and vocal process churn as consultants and authors split and competed over Kanban, Lean, and every new project-management prefix-of-the-day…
Taken from Extreme Programming, a Reflection, by Uncle Bob
Well, I’m glad I’m not alone in those feelings! But the core question, which will continue recurring, is: can you truly understand Agile, or any development methodology, without having done that most fundamental development work: programming? My gut and experience tells me absolutely not but yet we continue to hand over control of our development methodology to people who have never done programming, personally or professionally. I doubt I am alone in this sentiment.
And then there’s W. Edwards Deming, the stepfather of the modern Japanese automotive industry and Lean movement, who was not in any way initially a car guy, who was a statistician by education and practice. I could dismiss his profound success and influence as due to his brilliance or individual abilities, but I feel it’d be unfair and simplistic. I suspect serious insight can be made by having a “process expert” who is not an expert in the subject matter. A voracious reader, experimenter, learner, statistician. But rare. Not many are needed; those that are should be coaches and not managers.
Deming was disruptive, and unaccepted in America. “No man is a prophet in his own land.” Is the project manager running your standups Deming-like? Is he applying the principles of Lean and Agile, or just the tools of Scrum? Do retrospectives involve questioning the entire system, or have they degenerated to complaints about other teams?
I’m not saying your project manager is doing a bad job, but he’s likely no Deming. So should he be responsible for the implementation of Agile? Agile is, at its core, about creating tools that support principles that govern the way programming and development is done. Why should this be up to someone that doesn’t program, and never has? What outcome do you expect?
Every original signatory of the Agile Manifesto has experience as a software developer (or in one case, tester).
Programmers: take back ownership over Agile and the way you work.
regarding the original question – quite likely, if it’s explained well and not just thrown at people as in “We’re calling whatever we do from now on “Agile”. What is Agile? No need for YOU to know, just do what we tell you…”. Then take your average production artist who has the attitude “whatever, just tell me what to do and let me get back to my ART!” and you can see why Agile isn’t just working for anything non programming in most places.
I remember my introduction to Agile, back when I was a modeler… thinking back, it reminded me mostly of some buzzword bingo festival. But then again this is nothing new to Agile. You can’t just explain domain specific terms by using more domain specific terms. You gotta sit down and explain the whole thing in plain English, and then the ideas behind Agile are pretty simple and make sense.
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?
Does it matter? To me a project manager’s role is to remove obstacles that take time away from a team to deliver software. The implementation of how the team organizes itself to deliver the software is the responsibility of that team.
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.
What is the answer you want? If the person running the AGILE team has done programing then they are biased to that part of the team, and mange from the view of “I know how to do your job so I know best” attitude and doesn’t relate well to the rest of the group, design and art and audio.
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.
Brad, very thoughtful post, thank you.
If the question would be: “can someone optimize development-processes without the knowledge of programming” I would say yes. you should have played soccer (at least a little) to be a soccer-trainer.
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…
I wholeheartly disagree with you, but in a non-violent way Rob ;-)
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 :)
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.
@ Rob G.: What about trust? Isn’t it trust that is missing when I need to deeply understand and try to predict what the team will decide? As Anko says: it’s the job of the managers to give the teams enough air to build great software and that needs a lot of trust. Of course trust is more difficult without understanding – but on the other hand that is real trust. I totally agree with what Anko says.
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.
Agile is obviously and inherently biased towards software development from the perspective of programmers. I was reading through the principles the other day and musing on how well they fit game development. There are a number that don’t fit as well as they do with other software IMO. Whether that’s because something in the way the industry is normally organised needs to change or whether it’s as you allude because large parts of the process involve disciplines in much larger numbers that you wouldn’t usually see in more technically oriented software.
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.