In my continuing quest to identify the skills it takes to be a top ScrumMaster, I took ten random (current) ScrumMaster job postings to take a look at the top words that came up when employers were trying to identify their ideal candidate and the results were interesting.
*note: I excluded obvious words like 'Scrum', 'Agile', 'Master', etc
Let's look at a few of the more interesting ones:
Team
Team is the most common word throughout these ten job postings and I think tells an important story about what a good ScrumMaster does. First and foremost, SMs are members of a team. They are not greater than the team nor can they separate themselves from the successes or failures of the team. If the project fails in the eyes of the stakeholder, it is inappropriate for the ScrumMaster to respond with comments like "the developers weren't getting their work done efficiently enough," or even worse, "the team wasn't communicating well." If the team fails, you are just as much to blame as everyone else; don't use your position as mouthpiece for the dev team to throw people under the bus.
Solutions
Everyday I come into the office, there is a list of problems (most of them urgent, the sender suggests) that need to be solved. Everyday I leave the office, there is a list of problems. One approach is to stop the presses until all of the day's problems have solutions, but if you head down this road you'll quickly find out that you and your team will be running around like chickens with their heads cut off as the urgent requests never stop. The alternate approach is to organize the team in such a way which maximizes their ability to foresee problems and adjust around them before they make it into production. A constant line of communication between team, product manager, & stakeholder(s) will ensure that you find more of these solutions during feature development than after deployment. This is a ScrumMaster's core responsibility. Don't be afraid of problems... there will be many. Communicate and adjust.
Transparency
The last thing a stakeholder wants is for their development request enter a black box from which sometimes things exit and others get lost into the nether. It's the job of a ScrumMaster (with the help of the Product Manager) to ensure that the team's progress is open for all to see. Whether it's burn-down charts, company-wide release notifications, more visible tracking tools, etc, the ScrumMaster must make sure that stakeholders and management understand what will make sprint release, which roadblocks were faced & overcome, and any other developments which alter timelines or features to be released. If they can't see what the team is doing, it's likely that they think little is being done and that agile doesn't work. Don't let this happen; be transparent as possible.
Manager
*WATERFALL ALERT!* *WATERFALL ALERT!*
As members of agile teams, we all know that ScrumMasters are not called ScrumManagers. The 'M' word was left out of our title for a deliberate reason. We aren't managers in the traditional sense of "you do this," and "you do that." It's incredibly time consuming and limiting if we were to run the agile teams as micro-managers. Still, it shouldn't be lost on the reader that the word 'manager' comes up so often in a ScrumMaster job posting. It shows the amount of work we still have in evangelizing the business to understanding what agile/scrum truly is. If you have your pick of work, I would suggest avoiding job openings where the term 'manager' appears more than 'agile' or those which fluidly swap 'ScrumMaster' with 'Technical Project Manager'
No comments:
Post a Comment