Your Reputation Precedes You

How do scrum masters search for jobs?

Just like anyone else.  We check openings on places like Indeed, Dice, and LinkedIn.  We submit resumes.  We go to interviews.  We network as much as we can.  In fact, we network A LOT.  Most people in the tech industry get jobs based on recommendations from their peers.  Let that sink in for a moment. 

How others perceive you – your reputation - can possibly determine whether or not you get a position you really want.

However, the tech industry is both smaller and larger than you think.  A scrum master’s reputation can either be a great boost to his/her chances for employment, or it can be the biggest hindrance there is.  Take Denver, for instance.  There is a large tech industry here, but as far as metropolises go, it’s also a small place.  Therefore, many people who call Denver Metro their home have worked with each other in some way, shape, or form.   Project managers, developers, testers, system architects… they all may  have worked together at previous companies.

Recruiters know this and leverage social media sites like LinkedIn to dig up any dirt they can while pushing candidates through the hiring process.  I once applied for a job through a recruiter; her client searched for me on LinkedIn and discovered that one of her QA Managers used to work with me.  So, she pumped him for information and even got him to contact me via email.  Because I trusted him, I gave him a little too much info about why I was leaving my then employer, and she decided she didn’t want me after all.  It was sneaky on my former colleague’s part, but it was my fault, too, for not being a little more reserved.  Had my former colleague worked with me beyond one crazy project, he would have known I was a capable leader and scrum master and probably could have defended my position a little better… that is, if he had been so inclined…

My point is this: your reputation can depend on anyone’s perception of you, and ANYONE can gain access to your former colleagues through LinkedIn.   For more reasons than this, you should always conduct yourself in a professional manner.  You never know when a bad day will come back to haunt you. 

In addition, never underestimate the power of cultivating the relationships in your network.  Touch base once in a while just to say hello.  I know that seems like a no-brainer, but you’d be surprised how many people ignore this little gem of social etiquette.  One woman I worked with years ago recently contacted me out of the blue and asked me to critique (aka edit) a cover letter.  She even asked me for a reference.  I hadn’t corresponded with her in over two years.  She didn’t even bother with the niceties of asking about my family or my current job situation.  I told her no on the basis that I hadn’t worked with her in the field for which she was applying.   I also had no time to edit cover letters.  Asking for favors is difficult enough as it is.  Asking for them without having an established relationship is even more so.

Should you continue to leverage your network to gain employment?  Absolutely.  In this Age of Information, however, be proactive in cultivating your reputation AND your relationships.  Make the most of everything, and you’ll increase your chances of landing the job you want.  

Managers CAN Help Self-Managed Teams!

One of the tenets of agile is forming self-organizing teams.  This brings autonomy and ownership to the teams that helps promote the agile value that favors individuals and interactions over processes and tools.  If the very definition of a self-managing team is a self-organized, semi-autonomous small group of employees whose members determine, plan, and manage their own day-to-day activities and duties, then what is the role of the manager?  Many have argued that if we have self-managed teams, then we do not need managers.  However, there always needs to be management or else teams can decline into chaos.  

So how much value does a manager bring in a self-organizing environment?   Plenty.  This “external leader” walks the line and can manage the boundary between the team and the rest of the organization, for starters.  She can build relationships, gather and share information, empower the team, and facilitate group processes as well.  She can coach the team in agile best practices while also facilitate meetings and coordinate schedules.  In short, a good leader of self-managed teams tends to do all these things and more.

Managing the boundary between the team and the larger organization can be a very delicate dance for the leader of a self-managed team.  While managing that boundary, the leader needs to give direction to the team from higher levels in the organization and also report team progress/ status back to the higher levels.  The leader basically represents the team’s interests in this flow of communication.  This also means that the leader must manage accountability; she holds the team accountable to the goals it sets for itself and also takes responsibility when those goals are not met.  The buck stops with the leader, and a good leader will lead her team by example.  

Managing that boundary also requires you to build strong relationships both inside the team and out of it.  Again, this is an agile value and can only help the leader of a self-managed team.  Outside the team the leader needs to be both socially and politically aware of the organization she works for.   Knowing how to navigate corporate politics will make her an asset to team so she can gain traction for their project needs.  The leader will need to know how to gain external support for her team, and that means knowing the right people to contact when the need arises.  Within the self-managed team, the successful leader will have also built team trust.  Empowering the team by encouraging the make their own decisions and then delegating the authority to follow through on these decisions helps tremendously with trust. 

Another way a leader can provide value and help to a self-managed team is by gathering and sharing information.  In agile projects, we want collaboration and transparency.  By seeking information from managers, peers, and specialists, a good leader can use this information to help diagnose and remove impediments for the team.  This keeps the team’s momentum going forward rather than being interrupted.  It also keeps the rest of the organization informed, as noted earlier. 

That momentum can be kept going in a myriad of ways, and the leader of a self-managed team is the right person for the job!  Having knowledge of the team’s work practices definitely helps in this area, but the leader can help facilitate the ceremonies of an agile project (planning, retrospectives, schedules, etc.).  Getting the project started and keeping it going is something the team doesn't necessarily have the bandwidth to handle, so having a leader to keep things going and help the team respond to change benefits everyone.

Overall, having a leader on a self-managing team is not as oxymoronic as it sounds.  Whether it’s managing the boundary between the team and the organization or simply keeping things moving forward, the successful leader can help behind the scenes to keep the cogs of the well-oiled, self-organized team on track for success.  

Backlog Grooming

I was going over some backlog grooming ideas with one of our Product Owners recently, so I thought I’d share these ideas with everyone.  

When preparing for sprint planning sessions, please take a moment to make sure the top 20 stories in your project backlog are “shovel ready”.  What do I mean by this?  Shovel Ready means that the stories have advanced to a state that allows teammates to IMMEDIATELY start working on them.  Ideally, this should be done even before Release Planning, but that can’t always happen.  

Here’s how we get them shovel ready:

·        UAC in EVERY user story

o   The team needs to know what the Product Owner’s definition of done is.  Your definition of done is your user acceptance criteria.  Don’t leave this to sprint planning.  We tend to go down rabbit holes as to what DONE actually means.  Product Owners, it is your job to set this standard, and it is the team’s job to tell you whether or not your UAC is possible in the context of the story.  THAT’S what needs to be discussed during planning. 

·        Possible story breakdown

o   Evaluate your user stories so succinctly that you can foresee whether or not they need to be broken down into smaller stories.  If you think you can group certain data flows or business rule variations, then do that ahead of time.  If you are not sure how to break them down, check out Richard Lawrence's How To Split a User Story again .  If you’re still at a loss, then by all means bring it to the team. 

·        Prioritize the backlog

o   Have the most important things you want worked on AT THE TOP of the backlog.  Make sure the team knows this priority, and make sure this priority is reflected in the goals you set for the sprint. 

·        Story Language

o   Please try to write stories in the format of “As a <blank> I want <blank> so that I can <blank>”.  This helps us keep the end user in mind.  I understand technical stories come up, but we need to try to stick to this idea as much as possible.

o   Be very specific in the language of the story.  Make it reflect the end goal.

If you have any other ideas you’d like to share, let’s share them!  Let me know if you have questions, as well.  Each of you have your own awesome style of handling user stories, so I encourage you to learn from one another as well.