|
Scrum has relied upon a growing army of Certified Scrum Masters (CSMs) to shepherd the practice of scrum within teams. I won’t go into the various roles within Scrum, but suffice to say that the SM is supposed to a heroic servant-leader, championing a methodology, removing obstacles, keeping the team humming along. Those are some fantastic burdens to place on someone who only needs to go to one two-day course and pass a ridiculously easy test in order to get accredited (I’ve never heard of anyone who didn’t get certified at the end of a class). It’s also a set of expectations that in the corporate world equates to a project manager, and therein lies the rub.
It’s no wonder then, that most ScrumMasters are just project managers in disguise. Just reading the list of their duties would read to most people as the definition of a project manager. Sending off a project manager to ScrumMaster training is something that every organization I’ve worked has done. Scrum - The corporate way The results are as predictable as they are recognizable as a corporate remake of scrum. Most of the check-marks are checked and if a paper test of the application of scrum were all it took, I’d wager that every organization that claims to practice scrum would pass. The practical impact is far less recognizable, and the genius in a hobbled scrum implementation is that the inherent lack of transparency and metrics precludes answering questions about how much scrum is actual helping. Separating the PM from the SM Developing agile processes requires an organization to divorce the project manager hat from the scrummaster role. A simple approach I’d propose is to to keep the management and decision making around human resources and strategic roadmap outside the scrum team and the scrummaster, and empower the scrummaster to inform those decisions based upon the empirical data that is produced as part of doing the work of the team. Those information radiators are key here -- yes, those same ones that are often conspicuously missing or neglected, with historical data showing on them until someone does the honorable thing and just erases the board or removes the papers from the wall. That first step will inevitably lead to many more, as the team decides what information to share and management figures out how to glean the data and make meaningful use of status.
2 Comments
Scrum as a methodology is afflicted by taking inordinate metrics on the mundane, hoping to find logic and patterns in a stream of measurements and numbers. Often times teams are consumed with devising the means to measure productivity, velocity, veracity… all of which point to the distrust that is inherent in every organization i’ve worked with, to the natural order of self-organizing teams.
In physics, there’s a concept of the Observer Effect, wherein the act of observation itself changes the phenomenon being observed, and that’s entirely applicable to to scrum. Managers wanting to know exactly what people are working on, but the focus on smaller and more invasive measurements betrays a lack of trust that’s inherent to erstwhile big-design scenarios. I’d advise organizations to focus on the hiring process, to bring in great people and then get out of their way as much as possible. I like the agile manifesto’s take on this: projects are built around motivated individuals, who should be trusted. That that to heart so that the next time you’re thinking of another metric you’d like from the team, think instead of whether you’d prefer the measurement to be done or the work to be performed. More metrics invariably leads to lower productivity. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |
RSS Feed