Talent vs Tenure

March 28, 2015 Leave a comment

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.

Filed under Uncategorized Tagged with ,

Why I Would Never Go “Enterprise Scrum”

April 19, 2011 1 Comment

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.

Filed under Agile, Process, Scrum

Your Scrum Team Might Be Too Big

January 4, 2011 Leave a comment

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.

Filed under Agile, Scrum, Teams

Scrum Does Not Tell You How To Build Stuff

November 6, 2010 Leave a comment

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.

Filed under development practices, Process, Scrum

Tips on Knowing if Your Daily Scrum Sucks

October 18, 2010 3 Comments

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?

Filed under Agile, Meetings, Process, Scrum

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

September 28, 2010 Leave a comment

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?

Filed under Agile, Scrum

Effective Meetings Mean More Than Discussing

July 12, 2010 Leave a comment

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.

Filed under Meetings, Process

Scrum Won’t Always Work

June 7, 2010 3 Comments

Well, this is my fourth refactoring of this post. This was supposed to be a quick one! I fully intended on this post explaining why Scrum will always work. Simple! But, as I thought through this, and kept rewriting my post, I’ve completely changed my tune.

What does it mean for Scrum to “work”? I’m going to define “working” as “delivering more to your customers with higher quality than you did before and continuously getting better”.

Does Scrum always work? In my opinion, no. It depends on the type of team that is being introduced to Scrum whether nor not it will work.

The Team that Rocks

If you have a team that is consistently delivering value, is a cross-functional “team” and not a group of individuals, is continuously improving and has a good, productive relationship with their customers where the customers define what they want and collaborate with the team, then Scrum may set them back. I believe that the additional overhead in the form of sprint reviews, retrospectives, sprint and release planning, and daily stand-ups that Scrum adds may make an already high performing team less productive. The team, in some form, is already doing something that produces the same results as these activities. For these types of teams to improve, Kanban is likely be more appropriate.

The Team that Does Not Rock

I really wanted to title this “The Team that Sucks”, but I thought that would be too offensive. Anyway…Given a team that is not consistently delivering value, is not a real “team”, or has a bad relationship with their customers, I believe Scrum will always work. The team will always be better than it was before. Typically these teams have no process (even though they think they do), so anything that brings discipline and communication will allow the team to improve. I have never, ever seen this to not be the case. I admit that at times the improvement is small, but it is an improvement nonetheless. Of course one thing that’s crucial is to have a strong, experienced coach.

As far as the roles introduced by Scrum, you will have a hard time convincing me that there are times when a product owner role is not needed. I’d have to say that the #1 problem I see in “troubled” teams is the fact that they have no idea what to work on next. What do they do in this case? They start guessing. Oh, and they never really know when they are “Done”. If I do nothing else but involve a strong product owner, that alone typically propels the team forward.

As the team matures, however, they will inspect and adapt (the essence of Scrum). Many “advanced” teams may be considered by Scrum-ists to be doing “Scrum-but”, or maybe even not doing Scrum at all, since they have adapted to be the most productive and efficient they can be. Which helps verify that Scrum will not always work.

What do you think? Will Scrum ALWAYS work?

Filed under Roles, Scrum, Teams

Stop Talking, Start Drawing! A Quick and Dirty Value Stream Example.

March 25, 2010 2 Comments

Recently I was helping a team out in a sprint planning session. All development is very waterfall (that’s a topic for another post), and it follows a very well defined, albeit inefficient, process.

We were talking about how to “streamline” the process to deliver this particular product, which was nothing more than an electronic representation of a printed document.

We talked and talked. We were “talking” about the process. I decided to draw the process we were talking about so the entire team could visualize it. It is a very quick and dirty value stream map, and can be considered incomplete, but sufficient for the needs of the team at this point in time.

Below is a re-drawing of the first stab minus the “details” 🙂

Delivery Process

I then asked the team if there were any opportunities to improve. The collective answer was “no, the process is already streamlined“.

Okay, sweet. But, I’ve never seen a process that can’t be improved. Ever. And I’m old.

Then I asked how “long” we stopped at each step in the process, i.e. how long each step took. Below is the same drawing plus the weighting.

Delivery Process With Weights

Delivery Process With Weights

Notice any thing interesting? Anything stand out? Well, I’m sure you caught it. The “unit test” box is 40 hours, while everything else is 8 or less. Hrmmm….I wonder? Could we maybe do something there?

Well, we explored it a bit, and found that how we’ve been doing things is throwing them over the wall so the consumers of the documentation can eyeball and test this stuff. Guess what they did if they found something wrong? They spent time creating a document to tell the developers what to change. Then, back around it went.

So, an option the team came up with to reduce the time spent in the unit testing “state”, was that when unit testing began, they would have the developers sit by the folks who actually tested the documents, then they would “tell” them what to change…then change it…then send it back to test. No emailing and creating painful documents describing what’s wrong. Just good old fashioned face to face conversation. The team is confident that they can significantly reduce the 40 hours of unit testing.

Will this work perfectly? No. There will be more opportunities for improvement…as always. But, you know what? We would have never explored this option of we would not have visualized the process by drawing it.

Oh, guess how long this took us? About 20 minutes. Yup…20 minutes. That’s it. How long did we talk in circles before we drew? Hrmmm…about 1/2 an hour, and it got us nowhere.

So, as soon as you start talking and talking and talking and talking and getting nowhere. Get off your butt, and start drawing.

Filed under Process, Teams

Scrum Needs More Than Just Chickens and Pigs

March 21, 2010 2 Comments

If you’re reading this, I assume you already know the “chicken and pig” roles in Scrum.  If not, go here to check it out.

Okay, pigs have “skin in the game”, and chickens…well…don’t. Since some people hate the chicken and pig metaphor, I’ve also referred to it is “committed” (pigs) and “interested” (chickens) (I didn’t come up with this, but I don’t remember who did).

The chickens are not allowed to talk in the daily Scrum meetings. They are only allowed to provide feedback in the Sprint Review (and of course at any time to the Product Owner, Scrum Master, or as requested by the Team).

I think there are two kinds of chickens. There is the kind that provide no valuable input. They historically have done nothing other than cause distractions. Whatever it is your building may have an indirect impact on their lives at best. These people are typically in some kind of management, or senior role.

The second kind of chicken are those folks we typically refer to as “SMEs” (Subject Matter Experts). We may or may not be building a solution for them. However, we rely on their expertise to enable us to deliver value. These kinds of chickens are usually are involved in legacy application development or re-platforming efforts. You probably won’t experience this group if you are doing new development. These types of chickens are needed when the Scrum team just does not have enough of the institutional knowledge needed to consistently deliver value.

Both of these types of chickens have one thing in common. They do not have “skin in the game”. If the project fails or succeeds, there typically will be little (or no) consequence for them. What they do NOT have in common is this; the involvement (or lack thereof) of the second kind of chicken can either bring a team to success, or to a miserable failure.

Teams will typically lump both types of chickens together and treat them the same way. It’s really insulting if you think about it. If I was *critical* to the success of a project but am labeled a “chicken”, and if I identify a risk, I shouldn’t have to wait to speak until spoken to (which is implied with chickens), or until the Sprint Review.

What do we call this third group? They really aren’t chickens as defined in the Scrum context. However, they aren’t pigs either since they aren’t the Product Owner, Scrum Master, or Team (those who do the actual work). We will fail without them.

Filed under Process, Roles, Scrum, Teams Tagged with ,

← Older posts