One of the 12 principles of Agile Manifesto states: "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."
Most often this is taken as a purely technical injunction e.g. servers, tools, etc. However, there is an important dimension of human motivation that is not directly addressed in any of the Agile methodologies or in many of the actual practices: Career progression and, more simply, pay.
Historically, companies addressed this issue via a matrix structure with tiers of seniority and columns of capability. Career (and pay) progression involved moving up the tiers of seniority, one by one, in a single column of capability (e.g. junior tester to senior tester to team lead) until the capability columns merged at certain points (e.g. head of testing promoted to head of all development).
For good reasons, Agile implementations have disrupted the traditional organizational certainty by introducing roles that significantly improve software development value delivery and enhance the working experience of the participants. Agile implementations have also flattened or removed hierarchies (e.g. people can change roles from junior tester to Scrum Master to senior tester), removed whole functions (e.g. the Project Management Office), challenged managers to become “servant-leaders,” and encouraged individuals to broaden their capabilities across several of the old functional boundaries.
In many cases, organizations are “force-fitting” the new Agile roles to the existing seniority-capability (grade-pay) matrix. Transitioning between different Agile roles as its champions envisage becomes challenging. When niggling thoughts about absolute and relative pay and grade levels get in the way of autonomy, mastery and purpose, Agile implementations are doomed to failure in the long run.
So what’s the answer? We think we have one – and we’re excited to share it. Learn more here.
DCG President & CEO