There is a common misconception among people who are just starting out on the agile path that the agile model favors developers and downplays other roles. While it is true that agile puts a greater focus and added responsibility on developers it also broadens the definition of developer from the niche of "people who write code" role to a more umbrella term of "people who deliver software".
Ultimately though the agile methods that are technically focused are about ensuring quality of delivery. Delivered features should be "done" rather than thrown together an handed over a test team to let them find the issues - a common side effect of time constrained, fixed scope, phased delivery. That practice is unacceptable even in plan based or phased models and regardless of the project approach a development team can and should be making use of practices often associated with agile.
But other roles necessary in the delivery of a project also benefit greatly from agile approaches. Just think of some of the things these other roles would do within more traditional project delivery models,
- Who has to spend days or even weeks manually running the same few hundred scripted tests every few months to avoid regressions and assert correctness of the system? Not the developers thats for sure. Testers are often required to execute manual scripted tests which are slow, prone to error and have a relatively low ROI compared to other testing techniques. Manual tests check for issues you know will break your system, but its the unknown issues that typically kill your solution. Automation of these tests (by developers and testers) gives faster more frequent feedback and allows testers to actually do interesting, rewarding, more valuable testing such as Exploratory Testing. Testers should not be there to break things but to ensure we build the right thing right in the first place.
- Who spends weeks going through multiple versions of documents that seldom get updated and go out of date shortly after sign off? Again, not typically the developers. Business Analysts and Solution Architects spend a long time producing documents that create a contract for all parties involved. Often, though, they are only pulled out during "disputes" around agreed functionality (between either developers & tester or customers & analysts). If that happens though, then who is actually reading these things properly? No matter how rigorous you make documents there will always be the problem of interpretation. You can't misinterpret a running solution.
- Who is expected to "manage expectations" when delivery is slipping beyond the scheduled dates?. Long running projects that pin all their plans on up front estimates will slip. It's inevitable unless you've managed to overestimate everything but then I'd wonder why you are doing the work and not your more aggressive competitor. When this happens it's typically the job of the manager and senior technical folks to inform the customer in the best way possible, to "manage their expectations" (shudder). No one wants to do that. In typical agile models visibility is a key differentiator (another way to ensure quick and frequent feedback) which removes the need to for big bang disappointment. When things change or slip you know about them much quicker and can course adjust, the impact is significantly reduced.
All these (arguably wasteful) practices are typically the responsibility of people in non-developer roles. Now that we have reduced or removed these practices does that mean we've made the roles redundant? Not at all - as with the developer role increasing in scope so does the manager, analyst and tester. Testers no longer just "test", they have a more important function - assuring that what they test is the right thing, they've become crucial to analysis. Analysts also need to understand aspects of project management and managers themselves can move to a more hands-off sales and account management role as delivery is managed by the team itself. What we will see is a reduction of specific titles on projects, most people no longer fit those niche titles.
Facilitators & Implementors
So, yes, agile approaches certainly favour working software over volumes of documentation describing what the system should do but heck - so does common sense.
Agile approaches flatten the role structure across the delivery of a project. You end up with umbrella terms like facilitators (who ensure the right thing is being built) and implementors (who ensure the thing is being built right).
You go from this,
To something more like this,
If you wanted to map these intentionally nebulous terms back to typical roles in a more traditional model you have,
- Facilitators - Business Analysts, Solution Architects, Customers, Stakeholders, Users, Testers, Project Managers, Legal etc.
- Implementors - Developers, Testers, DBAs, Designers
Its clear to see where the commonplace agile roles fall as well - Product Owner and Scrum Master would be facilitators and the team would be the implementors.
Already, even at this high level you're getting overlaps and in many ways everyone plays their part as both a facilitator and an implementor but its generally obvious what a persons primary function is and you can plan around that accordingly.
You don't need fancy, lofty titles because you have a single purpose. Titles only force attribution of responsibility to particular people, they enforce specialism and defensive attitudes. Titles shouldn't affect the delivery of a solution.
So, no, "agile" is not just for developers, it's for the facilitators, the stakeholder & the implementors, it's an all-encompassing first step on the road to refocusing our goals from following a process to delivering the right thing quickly and painlessly.