Continued from 2013/04/15/lessons-learned-as-a-scrum-master/
Here is my list of lessons learned throughout my tenure as Scrum Master, and I’m sure there are many more that I missed. These were notes directed to myself, and are very project specific, but they give a decent overview. Each one of these was something that I messed up at one time or another, and is a little embarrassing to share, but I think that others could learn from it. I’m lucky to have coworkers who give me candid feedback so that I can work on improving these things. I’m much wiser now than I was 17 months ago.
Remember, making mistakes is ok, as long as they are new ones.
– When the sprint ends over a holiday (like MLK day), no one is going to want to review your code that day. Get it out there ahead of time.
– Don’t leave your teammates alone to watch for a green build, because cause it’ll break and then they’ll be stranded.
– Watch code freeze emails. Don’t push on a banned build.
– Be careful when rerunning unit tests as the results can get buried in the output. Make sure to do a full recompile before pushing.
– Make sure all code reviews are seen by a member of another team – even over-the-shoulder one liners.
– Don’t schedule
– Don’t mention tech debt on PSI planning slides.
– Be aware of your audience. Don’t give managers details that they aren’t necessarily concerned about.
– Be aware of your tone. Don’t present “casual”, you were the only one who presented casual.
– Beware of hubris. State facts, but don’t brag.
– Never use the word “safety” in an email, especially in the subject line.
– Don’t put words in people’s mouths.
– Always use a greeting in an email, otherwise it sounds very abrupt .
– Don’t bold things or use all caps, it’ll seem like you’re shouting at people.
– If an email seems emotionally charged, ask for someone to proof-read it.
– Your team isn’t looking for a friend, they are looking for a leader.
– The minute you are leading people, you start losing friends.
– Don’t expect anything of your guys that you wouldn’t expect from yourself.
– That being said, hold yourself to a Higher Standard.
– Dress, Effort, Accountability. If they work 10 hours, you work 11.
– Don’t call yourself a “Scrum Mom”.
– Make sure you demonstrate a “sense of urgency”.
– Make sure your manager can read you – make him comfortable by not making him guess what you’re thinking.
– Again, know your audience.
– Stop saying “Um” during public speaking .
– Stop bowling over people.
– Don’t be a bull in a china shop, let other people talk, shut up and listen.
– Listen to your audience – especially over the phone.
– Get a binaural headphones for your conference calls.
– Always ask questions. If the head honcho says “These numbers are unacceptable.” say, “How would you like us to proceed?” Be respectful of the “alpha”.
– Pause between slides during presentations, maybe let someone else drive.
– Structure your arguments the right way (persuasive vs. fact-finding).
– Have more information available, only show that half the deck if they ask.
– Answer questions succinctly – start with “yes” or “no”, pause for them to either move on or ask additional questions.
– Get your hearing checked out.
– “Think before you speak”.
– Adjust level of precision on estimates – with lots of assumptions, you don’t want to give .1% precision.
– When someone writes you an email, respond with an email of the same rough length.
– People might not tell you when there’s an issue, especially if they like you. You can’t change this, but you can be aware of it and try to give them a safe outlet to vent their concerns (like the tech lead).
– Monitor when stuff gets pushed to default. Run ALL UX tests locally, get it to pass.
– Present the facts, and let the client make the decisions, don’t make decisions for them.
– When sending emails, especially addressing things like stop-ship issues, phrase it like you’re the one with the problem and ask them to help you understand.
– Don’t assign blame, especially when you haven’t root-caused the issue yet.
– Don’t write sharp and snarky emails.
– DO NOT TALK OVER PEOPLE!!!! Stop interrupting the client.
– Sign your emails professionally, always use your sig.
– DO NOT TALK OVER PEOPLE!!!! Can’t say this enough. Be mindful.
– Be mindful of what you say when you’re frustrated.
– Always always check to make sure there is a conf number when you are invited to a meeting and you’ll be offsite, otherwise the meeting will start and you’ll have no way of getting in.
– Having large stories that overlap sprints looks like a “smell” when you start something in 11-1 that isn’t scheduled for 11-2, and there is still unstarted 11-1 work. Avoid this by breaking up the task.
– Be aware of your mute button.
– Be aware of reclassifying defects, some can be moved to tech backlog if they blow up.
– Ask for help early.
– More communication to your manager when we might miss.
– Be more deliberate about your pairing.
– Pairing onsite and offsite devs is sub-optimal given the choice.
– Swarm on tasks to get them done.
– Get tasks done before bringing in new work.
– If you learn nothing else on this project you take from it that we are at our best when we can adapt and help out. The future is rarely fixed for the organizations we work for and we need to be able to work in an environment that is ever changing without undue stress.
– Put the architect as an observer on any review that is architectural, even if she’s not “required” to review it.
– Break up stories better – asking someone to review 10,000 lines is unreasonable.
– When you decide to break up stories better, make sure you actually go back and look at the stories in the backlog and break them down – not just the new stuff coming in.
– Make sure you’re not “sandbagging” your commitments.
– Be careful what higher up managers say. They oversee the project but aren’t as close to the details as your direct manager.
– Before making a big announcement, double check with your manager. Plans can change over the weekend.
– If you have a problem with a dev from another team, go to their scrum master first.
– Save your righteous indignation for when it really matters, so that it does not lose its potency.
– Be wary of suggesting metrics that are easy for you to gather but a pain for everyone else.
– Address the right level. Corporate IT policy is difficult to change.
