Talent vs Tenure

First, I suppose definitions are in order.  Here are the definitions of talent and tenure from the Merriam Webster dictionary (http://www.merriam-webster.com/):

Tenure

  • The amount of time that a person holds a job, office, or title
  • The right to keep a job (especially the job of being a professor at a college or university) for as long as you want to have it

Talent

  • A special ability that allows someone to do something well
  • A person or group of people with a special ability to do something well : a talented person or group

Now that definitions are out of the way, let me first start with my own experience.

In the late 90’s, I decided to go back to college for computer science. I was 30 and knew nothing about computers. My wife actually had to teach me how to use a mouse. Ahhh, I can still hear her dear, sweet words … “Double Click!!  NO!! NOT THAT FAST!!!!!”.

So there I was, in the computer science graduate program (I had an undergraduate psychology degree and did not own a computer) with a bunch of fresh-out-of-high-school super smart kids…and I just learned how to double click. I remember my first C++ computer lab. The instructor told us to “open this file on the desktop, select all, copy, and paste in the IDE”. Yeah, I had no idea what the hell he was talking about…copy? paste? IDE? huh? Someone took pity on me and helped me out. Whew.

Fast forward two years. During those two years, I rarely slept, read everything I could get my hands on, took on web programming side jobs that I was in no way qualified to handle, and ultimately caught up to (and surpassed some of) the fresh-out-of-high-school college students. I loved this stuff. I actually ended up administering those same computer labs where I originally had to have help copying and pasting and participated in a QoS research project. I loved what I was learning and doing.

There we were, at the height of the dot-com boom. I saw so many people graduate that I felt had average (at best) software engineering skills getting high paying jobs. I, on the other hand, was still attending classes, living in a two bedroom apartment with my three small kids, and riding my bicycle 5 miles (one way) to campus. I was really, really tired of living on student loans and not being able to afford ANYTHING. So, I decided to see what I could find, even though I didn’t have my Master’s degree yet. I believed I had gained skills that had surpassed many that had already graduated…this should be easy, right?!

My resume contained about one and a half years of “real” non-college work…which was actually quite a bit exaggerated…but dangit…I KNEW I could take on any programming job!

To my surprise, I couldn’t even get my foot in the door. If I did get an interview, it always ended up with “yeah, you just don’t have enough experience”. ARGHH. I didn’t have the tenure, but I knew I had the talent!!

Months went by, and I finally landed a Cold Fusion programming gig…my first introduction to corporate America. It was a great and scary experience.

Now, fast forward another year. The dot-com bust. I was laid off with about 50 others.

Back to the job hunt. Well, evidently that one additional year of “experience”, i.e. “tenure” didn’t mean anything. Again, I got the “yeah, you just don’t have enough experience”.

Finally, I interviewed with a great guy, who ended up being the best boss I ever had, that for some reason believed in me. He was looking for talent…what I could deliver, and didn’t care so much about tenure.

That was an amazing experience. He gave me a chance. It proved to be mutually beneficial for me personally and professionally, and for the company. We were eventually acquired by a large company where I eventually became a software development manager, which was another great experience. The funny thing is that the large company who acquired us would have NEVER hired me directly since I didn’t have the tenure!

Fast forward to present day.  One thing that I’ve learned while being in the hiring seat is that hiring for talent is HARD. Hiring for tenure is EASY. I find myself looking over resumes thinking “wow, they have a bagillion years of experience, they must have talent!”.

So, I understand now why those hiring appear to prefer tenure over talent. It’s because it’s so hard to determine if someone has talent before you hire them.

I’m not saying that tenure means “nothing”. It is something that should be considered.  However, focus on talent first and foremost.  The two best programmers I’ve ever hired had absolutely no tenure at any company. They were fresh out of college.

Hiring for talent is hard. Take your time, be creative. Why not have the candidate join your team and pair program for a day?  There are a lot of companies that actually do this.  It’s well worth the investment.  Don’t assume that just because someone has years and years of “experience” that they are automatically talented and can deliver…you will regret it if you do.

Why I Would Never Go “Enterprise Scrum”

I’ve had some recent debates regarding whether we should start an “enterprise Scrum” initiative, i.e. WE WILL BE A SCRUM SHOP.  I would have completely supported this several years ago.  Now, I am completely against it.

In an organization of any significant size or age, there typically have been methodologies that have been introduced, pushed, then they fade away into the far recesses of everyone’s memories.  One characteristic of these methodologies is that they have very specific rules.  You can’t add to, change, or remove any of the rules.  Why?  Well, because you wouldn’t be “doing” X methodology!!!

People have a habit of dogmatically following whatever methodology management makes them follow.  Now let’s say we are doing “Enterprise Scrum”.  This means that you are performing the following ceremonies:

  • Release Planning
  • Sprint Planning (every sprint)
  • Daily Scrum (every day)
  • Sprint Review (every sprint)
  • Sprint Retrospective (every sprint)
And, you have the following roles:
  • (1) Scrum Master
  • (1) Product Owner
  • Team (self-organizing)
And you will have the following artifacts:
  • Product Backlog
  • Sprint Backlog
  • Burndown/Burnup charts (some say Scrum requires these, I don’t think it does as it’s not clearly articulated and varies by source)
So we’ve gone enterprise Scrum.  We’ve introduced this “by the book” Scrum.  However, we’ve also preached “inspect and adapt”.  But, in Scrum, the above items are non-negotiable…you can inspect and adapt all you want, but you can’t change the ceremonies, artifacts, and roles.  Can you add to them?  Sure, but you can’t “change” them.  And, in reality, making “inspect and adapt” a cultural “habit” is spectacularly difficult and rarely truly attained.

What if we have a Scrum team that wants to do a retrospective every other sprint instead of every sprint?  Blasphemy!!!  <finger-pointing> YOU are doing SCRUM-BUT!!! </finger-pointing>.  Really?  What if the team, Scrum Master, and Product Owner are all cool with it?  Now we have a bunch of stress, spinning, and politics because we want to make a change to our enterprise standard Scrum.  In reality, this is perfectly okay.  However, since we’ve pushed “Enterprise Scrum”, we have totally boxed ourselves in.  There will even be people who will not want to add techniques because “Scrum doesn’t say so”.  Do those people truly understand the essence of Scrum?  No.  But they will cause disruption and waste

What if you don’t want to do iterations?  What if you want to deliver continuously instead of iteratively?  No Iterations?!?!  Blasphemy!!!!  <finger-pointing> YOU are doing SCRUM-BUT!!! </finger-pointing>.

You know all of this could have been avoided?  By NOT saying we are going “Enterprise Scrum”.  I believe the best way to roll this out is by pushing Agile and Lean and what makes sense on a project by project basis.  Along with this there should be some foundational elements that are standard regardless of the methodology/toolset that is used. In addition, there needs to be a COE that can ensure that consistency is maintained without bureaucracy, and that knowledge gained is effectively utilized to continuously improve.

Please don’t misunderstand my intention here.  I am not bashing Scrum.  I LOVE Scrum.  I always use Scrum when I execute projects.  However, I’ve had rare cases within the same company where Scrum was NOT optimal, but Kanban was.  I was very thankful that Scrum was not the required standard.

Your Scrum Team Might Be Too Big

According to the ways of Scrum, the optimal Scrum team size is between five and nine people. Interestingly, I’ve seen this as a point of concern (sometimes contention) when I’ve coached people on Scrum. Please note that this is not a rule that must be followed at all costs. God gave us a brain, so we should feel free to use it.

While I know it’s rare, I personally have seen successful teams that consisted of 10-15 people. I belive that if a team consists of any more than 15 (or so) people, you are reducing your velocity.

Now you have a bloated team.  What should you do?  Well, first thing you should consider is to take some ideas from Kanban. Visualize the work, make the process and policies explicit, limit work in progress, measure/minimize cycle time, etc. (read more on Kanban here)   The purpose of all of this is to gain clarity on what kind of work is actually taking place.  In addition, you will gain insight into the quality of the deliverables and where the bottlenecks are.

Once you have this information in hand, you then have three choices.

  1. Split the team into multiple teams.I have seen large teams have several very distinct types of work occurring. If there are distinct types of work, i.e. completely different categories of stories/requirements with different goals, and the team is forced to act as one, then there is waste. For example, during the standup, there will be members of the team that have to endure hearing the updates about requirements that they have no interest in, nor can they contribute to the delivery of those items (usually). This is likely the optimal choice.
  2. Reduce the number of people on the team.This is the tricky one. You may find that there are people that don’t have the necessary skills, or you may find that there are too many people with one very distinct skill set. If one (or both) of these scenarios holds true, and you are sure that these folks can’t contribute in other areas, then make haste and remove the people from the team. Everyone (including those let go from the team) will end up happier and more productive.
  3. Keep everything the way it is.This is a very, very unlikely choice. I have never personally experienced a time when it was a good idea to keep one team larger than 15 people. I would love to hear from others where this has worked…well.

If you are a Scrum Master, and you are experiencing team bloat, then it is your responsibility to recognize it, determine if it’s an impediment towards improvement, then handle it.

Scrum Does Not Tell You How To Build Stuff

There have been some respected leaders in the industry that evidently just don’t get what Scrum is meant to provide and, more importantly, what it’s not.

Scrum does not tell you that you have to use TDD, BDD, Continuous Integration, Continuous Deployment, OOP, etc. Scrum also does not tell you that you have to use User Stories that are estimated with the Fibonacci-ish scale. It doesn’t tell you how and if to do exploratory testing, load testing, performance testing, acceptance testing, or anything else.

Why? Because it wasn’t meant to. Are all of the things I mentioned above good things? Absolutely! Is every team ready to adopt them? NO.

100% of the teams that I’ve coached were not ready to take on the additional stress of learning these practices that Scrum does not require. The FIRST thing they had to work through was how to be a team. How to understand what commitment means. How to respect and trust each other. How to feel and be empowered. How to build trust with the customer that had been long lost or most likely never existed. How to better predict what will be delivered. What it means to deliver VALUE.

Focusing on these things is many times almost more than a team can handle. I’m surprised that anyone would think it would be a good idea to right away add on top of this the pressure of learning new technical practices. The fact of life is that most enterprises do not have the processes, infrastructure, or culture that allows quick adoption of modern development practices. Change takes time. Take a deep breath and embrace it. Only then will you be able to make real change.

Tips on Knowing if Your Daily Scrum Sucks

Below are some tell-tale signs that your daily Scrum sucks.

  1. The team members stand at attention and salute the Scrum Master.
  2. There is an infestation of clucking chickens.
  3. You have a hard time hearing everyone over the loud yawning.
  4. There’s lots of very descriptive, helpful answers to “what did you do since the last meeting?” like “stuff”, “things”, or even better…”nothing”.
  5. The team members who did nothing since the last meeting happen to be the “rock stars” pre-Scrum…oh, and they never, never, ever, ever have anything standing in their way.
  6. Every meeting reminds you of the movie “Groundhog Day”.
  7. The first 5 minutes is spent waiting for the projector to warm up.
  8. You get to meet a new member of the team almost everyday, while never having a chance to say goodbye to the dearly departed.
  9. Most’s answers to “what are you going to do today”,  are “get sign-off”.
  10. Big Brother is there to make sure the team is “on track”.
  11. Most meetings consist of discussing episodes of “Fringe”.
  12. The meetings are typically very lonely, as you are the only one that shows up.
  13. Bullies are allowed to…well…bully.
  14. Everyone has their laptops open IMing each other about “how stupid this meeting is”, while the Scrum Master or Product Owner is assigning tasks.
  15. You get to hear intriguing, long presentations about each and every detail on things like how to install and set up subversion, or maybe even if you’re lucky you may hear why Lisp is the best programming language in the world!

While many of these are a bit tongue-in-cheek, they actually represent the many dysfunctional daily Scrums I’ve attended.  And yes, I’ve been guilty of participating in the dysfunction.

So, let’s hear from you guys!  What kind of signs have YOU seen that your daily Scrum sucks?

How Does a New Scrum Master Learn the Mastery of Scrum?

Learning to be a Scrum Master is hard. But what’s the best way for a new Scrum Master to learn to be a Scrum Master?

I had it easy. When I learned, I had an awesome team. They were open, engaged, and always wanting to improve. The Product Owner was awesome also. Again, open and engaged. The thing they all had in common was that they wanted to learn Scrum. I introduced Scrum to our department. I read a little, implemented a little. Screwed up, tried again. Read a little more, tried a little more. And so on. It was basically a self-study program with help from blogs, books and the team itself.

For me this was easy. I was never really a “command and control” person anyway. Sure, I had my tendencies, but pretty mild. I knew that my team were the ones that “really” knew what to do anyway…so why not give them the tools to empower them and help them be focused on quality and value? There wasn’t a lot of “unlearning” that had to take place for me.

After that first (great) experience, I became an agile coach. Now it was my time to help teams transition to Scrum by educating the team, Product Owner, and Scrum Master. Well, admittedly, I was winging it for a while, but through trial and error I fell into a pretty good groove.

What I’ve done recently is come up with three options/approaches to helping others become Scrum Masters.

  1. The coach leads

    With this approach, the coach plays the role of the Scrum Master, while the soon-to-be Scrum Master watches, and helps. Then, after a while (depending on their comfort level), there is a switch, and the coach becomes the observer/helper.

  2. The coach observes

    Here, the new Scrum Master will be the acting Scrum Master. However, the coach will be there to observe (and help) while the new Scrum Master is facilitating. The coach would only correct/advise/encourage in private.

  3. The coach advises

    In this scenario, the coach is not directly involved in any of the ceremonies. They are only there to advise. The new Scrum Master and coach would regularly meet to go over gotchas, issues, etc.

  4. Coach? What coach?

    This is how I learned. We didn’t have a coach. But, we were completely free to do what we needed to do to be successful. And, there was complete buy-in from the team and leadership. Oh, and we were allowed to make mistakes. And, I think what really made it work was that none of us had any “baggage” from other environments. I recently had change careers (retail to software), and most of the folks on the team were relatively fresh college graduates. After working with many teams, I’ve found that this is indeed a rare situation.

I give my team (and anyone else in the organization who wants to be a Scrum Master) those three options. #2 is the most popular. However, I just had someone pick #3.

So, which the best option? It depends. It depends on the experience of the new Scrum Master and of the team. It also depends on who the coach is in the organization. For example, I am a manager where I work. I don’t have the word “coach” in my title, even though this is something that I am responsible for. As with most organizations, having “a manager” present may send the wrong message, no matter how cool you think you are! There are some teams where there would be no issue, but there may be others where it might be questionable. You have to be aware of this, and make your decision accordingly.

As an independent consultant (coach), who is brought into an organization to introduce Scrum, then #1 is typically the best. If the coach is there to help “improve” their implementation of Scrum, or if maybe the organization is backsliding, then maybe #2 is best. When there are experienced Scrum Masters that are experiencing new situations and need to just bounce ideas off of someone, then #3 is best.

As far as #4…I’ve heard about many teams that tried to “do it on their own”, and completely tanked. They didn’t have that utopian environment that is oh so rare. So, if you do decide to do it on your own, start reading. Read, read, read, and read some more. Blogs, books, and user groups. Ask questions on these user groups…you will find a wealth of knowledge and people who want you to be successful. Also, twitter will be your friend. Personally, I have gotten so much out of following Mike Cottmeyer, Alan Shalloway, Ron Jeffries, Scott Ambler, Mike Cohn, and Esther Derby (to name a few). They post awesome information and articles that are thought provoking and hard to find otherwise.

I would love to hear from others on this topic. What are the approaches you have taken in coaching, or have seen others take? How did YOU learn to be a Scrum Master?

Effective Meetings Mean More Than Discussing

Many companies have been trying to reduce the overhead of meetings, to no avail. I have a really simple idea. Never set up or attend a meeting where the goal is to “DISCUSS” things. Here’s some examples of meeting invites I’ve had over the years:

  • Discuss technology direction
  • Discuss production outage
  • Discuss ORM
  • Discuss contract

Of course these meetings never have agendas. And what work is actually accomplished? None! A friend of mine compared these kinds of meetings to bar conversations. You know those; lots of fun dreaming about “what ifs” and coming up with a plan on how to “make it big”. And what happens after those conversations? Nothing. It’s as if they never happened.

Let’s rewrite those meeting invites to be a bit more productive.

  • Decide whether to build the application using .NET or Java
  • Create an action plan that minimizes production outages and define a clear escalation path in the case that they do occur
  • Decide whether to use Hibernate or EJB
  • Decide whether to accept or reject the proposed contract

Notice that the verbs imply finality, “discuss” does not. “Decide”, “create”, “define” means that you will leave the meeting having made progress. You now have a definition of “Done” for the meeting. You will never know when you are “Done” discussing.

Follow

Get every new post delivered to your Inbox.

Join 640 other followers