Recently I received a job opportunity in my inbox. This particular opportunity was for a Project Manager/ScrumMaster. This attempt to meld two distinct approaches signaled a warning that the rest of the job description amplified. When printed, the list of duties and skills took two pages, and the font was small.
While Agile is not truly a methodology, the manifesto and principles emphasize a lean approach. Those working to refine key Agile tools like Scrum are comparing it to lean manufacturing methods like Kanban. There’s no way a description for a role in a lean system can take two pages.
I’m not going to describe a proper job description for a ScrumMaster in this post. What I want to do is emphasize what I’ve said before, you can’t “be” Agile by adopting an Agile toolkit or naming your roles after Scrum. Thanks to significant work by pioneers in the ScrumAlliance, (www.scrumalliance.org) you can learn a lot about implementing Scrum. But applying Scrum tools doesn’t make you Agile any more than writing your code in Clases makes you Object Oriented.
If you want to be Agile, you have to change your thinking, then apply the tools that fit with your new approach. You have to stop thinking about “control” and start thinking about “allow”. You need to put aside “deadlines” and accept “opportunities.” Replace “roles and responsibilities” with “teams and accountability.”
This doesn’t mean that your projects are defined by chaos. In fact, if you apply the tools well you’ll have far more organized projects than your work breakdown structure ever gave you. But it does mean that you achieve that organization with the least overhead, replacing lengthy job descriptions with intelligent actors who do the right thing, even if it’s not the thing their job description said they would do.
If you can’t tell whether you’re truly becoming Agile or simply trying to apply Agile tools, find a good coach and let him or her take a look. This isn’t something you should just jump into on your own. Let someone who has been there help you find the way. Because if you try to implement Agile methods without becoming Agile, you will fail.