The Sick, Lame and Lazy Blocking Your Team.

Building a team is hard.

The hardest job for a scrum master is building a team. I spend most of my time acting as a coach encouraging people to work together.  It is not easy.   This week on the blog I want to talk about team building and my misadventures with it.  

The gold standard for all software development teams is Bruce Tuckman’s 1965 article “Developmental Sequence in Small Groups” which outlined the four stages of team development; forming, storming, norming, and performing.  According to Tuckman, a team moves through these four stages as they grow and develop.  My personal experience is that these groups of people can get stuck at certain stages and it is next to impossible to get them to move to the next state.  This is the biggest burden for a scrum master is nudging the team along so they can get to a performing state.  

The biggest obstacle for a building an effective team is what a former mentor of mine referred to as the sick, lame and the lazy.  These are the people who are going to make team building a chore.  When I refer to the “sick” I am talking about people who do not take care of themselves because it is not a priority.  These are developers who think they can come into wok hung over from a weekend revelry thinking they can use Monday morning to sober up.  Developers who refuse to get proper sleep also qualify as the “sick” because their mental fatigue is an obstacle solving the problems they encounter during the course of their day.  You also have to deal with developers being petri dishes of illness coming into the office.  With VPN’s and work from home strategies, there is no excuse that developers should be martyrs coming into the office to get the rest of the staff sick.  

The “lame” members of your development team are the people who lack the skills to succeed.  This means that other developers are going to have to work harder just to be successful.  In many cases this comes down to training.  More senior members of the team will have to take time out to train the more junior members of the team.  If this hurts velocity so be it because the short term hit will translate into long term gain.  A team member can also be “lame” if they do not share the same commitment to the project that the other team members do.  This is going to be the primary job of the scrum master to educate the “lame” team member as what is expected of team members.  Then they need to let the other team members use peer pressure to keep the lame member in line.  

Finally, you have the “lazy” team member.  These are people who think writing unit tests is someone else’s work.  They copy and paste code on a regular basis and when asked to refactor code respond with “It is working why do we need to fix it?”  These are the most frustrating members of your team and if they will not respond to peer pressure or your direct coaching they need to be managed out of the team – immediately.  This is because if other developers see this “lazy” person in the team not being disciplined they will think they do not have to work hard either.  This will create a cascading effect of laziness which will wreck your team.  You can forget about performing you are going to have a bunch of developers storming and eventually leaving because of your toleration of laziness.  

So if you want to be a successful scrum master be on the lookout for the sick, lame and lazy.  They are the unholy trinity of personalities who will wreck your scrum team.  

Until next time.

Beware the insubordinate guru

They look respectable but watch out!

Over my career I have discovered that many of the problems I have encountered in technology have been people problems rather than technology problems.  It amazes me how many damaged, mentally ill and plain mean people I encounter in the business world.  This is not what I expected when I graduated from college.  I was expecting people to behave like grown-ups when I began my career.  Instead, I found out that in the business world people can be more immature than when they were in high school.  This week on the blog I want to discuss a particular species of individual you find in the technology world – the insubordinate guru.

I mention this individual because I have been forced to come to grips with the damage they have done over the last year of my career to one of my agile teams.  You can spot these individuals in any organization.  They came up through the ranks and have a good amount of technical skill.  They believe that they are the smartest person in the room and often they are right.  With this confidence comes an ego to match.  When combined with some authority it can be a dangerous combination. 

The insubordinate guru will dominate an agile team and discourage collaboration with a kurt “no” or saying “we are not going to do this project this way.”  They will also spend a great deal of time doing things outside of the team such as building data access layers because the others on the team are not smart enough to do it correctly.  Finally, they like to dish out abuse to others but rarely can take it.  They also consider alternate ways of doing things to be “wrong” on a moral level. 

One afternoon, I overheard two developers arguing.  One was the insubordinate guru and the other was a new consultant who was teaching others how to apply test driven development to their applications.  The guru was incensed that the other consultant used a sample of his code to show how to refactor for test driven development.  Additionally, the guru said that the consultant would fail because he did not understand the culture of the firm I work and the he was wasting his time. 

This individual was toxic and hurting the project and the agile team.  In the end, confronted with a project six months behind and with upper management pressuring him he left the firm.  In his wake we discovered that he created a large pool of technical debt, openly defied upper management, and had undermined the agile process. It would take us four months to pick up the pieces and get to some semblance of order. 

Now that I have experience this first hand, I understand that the insubordinate guru has no place on any agile team.  They ignore the agile principle that the best architectures come from self-organizing teams.  They do not foster trust because they undermine the morale of people who are not like them.  Finally, they do not develop the agile value of respect but instead use their authoritarian nature to bully others.  They also lack commitment and courage because when things go bad they are not accountable but when things go well they are always front and center. 

You can talk all you want about Agile but only by working as a scrum master in the trenches to you encounter the types of people who will doom your team’s success. 

Until next time.   

Getting Emotional

It is easy to get emotional at the office.  

One of the hardest things I have had to master as a business leader and entrepreneur is my emotions.  A technology professional may not look like a bundle of frayed nerves but it is part and parcel of the career.  This week I want to discuss the role of emotions and how they play into life of a technology professional.

Before I worked in the technology business, I was a pit boss in a casino.  One of my mentors at the time made a point of reminding people “If you get angry you lose.”  In the hot house environment of a casino, late at night and with thousands of dollars at stake, people tend to get agitated.  It was my job as the guy in the pit to make sure that everything ran smoothly, no one cheated, and that everyone was having a good time.  It was not easy because you had to divorce yourself from all the different stimulus around you and focus on immediate tasks.  You also had to subsume your emotions because they would trip you during a conflict with a customer.

When I became a software developer, emotions came into play again.  I would spend hours attempting to solve problems and getting nothing.  It made you feel helpless and dumb.  It also did not help that your leadership was expecting you to solve the problem and then move on to the next topic.  This creates a feedback loop of frustration and self-doubt which makes it hard to step away from your work at the end of the day.  For example, one night I came home from work and spent the rest of the night muttering to myself about how I was going to get a web service to work.  It was so bad my spouse at the time said I was rattling off code in my sleep.  The next day I had a breakthrough and everything was right in the world but for a day my spouse had to endure me in deep thought.  This is not healthy to a person or a marriage.

Now, I have made the transition from software developer to Scrum Master.  This transition brings with it a completely different set of emotions.  I have deadline pressure from above.  I act as therapist and cruise director for the people on my team.  I also spend a lot of time in meetings when I really should be helping out my team members.  Finally, I have the joys of leading people who range from high achievers to clock punchers.  It is difficult and demanding because they look to you and if you are emotionally agitated; the rest of the team will be emotionally agitated.

So how does a software developer or Scrum Master deal with emotions?  Each person is different.  For me I spend a lot of time reading or attempting to unwind with movies.  I also use food as a coping mechanism which might explain why I am more pear shaped than most men.  Still I slip from time to time and tell someone they are being “lazy” to their face or roll my eyes at a Vice President who lacks my respect.  It is these emotions which define us and make the office such an interesting place.

Until next time.

Ninjas, Rock Stars and Gurus need not apply.

Software is like jazz.  You better have "chops"

Being a technology professional is a mixed bag.  You are part of a social and technological wave helping to transform the world.  At the same time you are involved in petty arguments, massive egos, job insecurity and the nagging feeling that your labors are making someone else very wealthy.  You are also a rare commodity and receive plenty of anonymous job offers from people hoping to fill roles.  You also get to interact with recruiters who behave like talent agents trying to get you the next big gig, for a percentage.  This week I saw a job posting for a company looking for a “web ninja.”  It made me think about what I was going to look for when I start hiring.

The world of technology is very Darwinian.  An individual either knows how to code or they do not.  Many times I use a term for jazz music and say that a developer has “chops.”  This is because it is not easy to take a nebulous idea and transform it into working, testable code.  These individuals are rare and hard to find.  It took me the first five years of my development career to develop chops as a software developer.  Then the market changed and I had to learn how to code all over again and develop “chops” in that skill set.  It is an on-going process of learning and relearning how to do your job.  Being unable to change and adapt will doom you to irrelevance and unemployment.

This is why I found the job posting for a “web ninja” so amusing.  Some employers are so desperate for talent with chops that they will do anything and everything to make their work seem “cool” and cutting edge.  The reality in technology is that most of the work is pretty mundane.  You are helping square peg systems communicate with round hole systems.  You are moving data from point A to point B.  Finally, many of the people who use your systems are not looking for the next big innovation but rather something which works good enough.

As a software developer and entrepreneur, I am not looking for ninjas, rock stars, or gurus.  I am looking for people who can work together in a team and have chops.  These are people who are not experts but are willing to learn.  These are people willing to mentor junior developers so that they can grow to their level of expertise.  These are folks willing to stand over the shoulder of a peer so they can together fix a gnarly bug.  In other words, I am looking for professionals who get the work done with quite assertiveness and a sense of craft.

A ninja will not document code or write unit tests.  I also suspect they will use the most complicated path from point A to point B.  Rock stars will refuse to change code after a code review and insist they receive all the attention when the project succeeds.  I will not see them take responsibility when code fails.  Finally, a guru has such a specialized skill set that they cannot see other ways of solving problems.  It is the old adage that if your only tool is a hammer everything else starts looking like a nail.  This is one of the few times I will agree with Robert Heinlein, “Specialization is for insects.”  A guru is nothing more than a technological insect.

So you can keep your gurus, rock stars, and ninjas.  I will settle for something a little less flashy and more efficient.

Until next time.