My team now has 4 Certified Scrum Masters. The process we have implemented is very scrum-like, but also incorporates other agile and non-agile practices. It helps for people to get certified for the roles they perform. If certification is available, and if it is monetarily feasible, I would highly recommend it. Certification not only helps the people to feel more empowered to perform in their roles, but it also provides the team with with trained people to help steer the course and champion the ideals regardless of approach. Now, if I can only find a way to get our customers certified as Product owners!
http://www.scrumalliance.org/scrum_certification
2 comments:
I certainly understand your desire to employ agile methodologies. It seems to be a way to keep developers very happy, and happy developers create mountains of great code! But as a manager yourself, how do you address the obvious conflicts that an agile methodology has with traditional project investment decision making? Executive management relies on answers to the vital questions of what will I get, how long will it take and how much will it cost. And what do you say to the claims that agile only works when you have a focused team? Getting a resource for a few hours a day or only a day a week throws a wrench into many of the practices that make agile effective.
Response to questions raised by Anonymous:
There is no "obvious" conflict between agile methodologies and traditional project investment decision making. The decisions required for choosing to invest in a project are part of project governance which Scrum / Agile is not.
Agile methodologies are mostly applied in the "Executing, Controlling and Monitoring" process groups of a project while the answers to those vital questions are required in the "Initiating" process. In truth none of the traditional project approaches, waterfall ISDMS, or Agile methods address these questions (scope, time, cost) with any accuracy in the early stages of the project.
Given the realization that we must decide to move forward early in the project based on estimates and educated guesses, we can expect a certain level of change to occur later in a project in order to compensate.
One key difference between Agile and traditional (waterfall) methodologies is that in an Agile plan change is accounted for as a natural occurrence in the process and not as a disruptive, unplanned event.
See Also: “How Scrum Adoption Can Curb Government IT Waste”
Post a Comment