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.

Focus and Flow

Success requires focus

The biggest challenge I have had as an entrepreneur is staying focused on what needs to be done and ignoring the issues which might get in the way.  This has been a bigger problem as I spend more time at home thanks to a hoteling scheme for all the software developers and project managers at my day job.  That is why this week I wanted to provide a bit of a meditation on one of the most important agile values I know: focus.

Working as a software developer is a very creative pursuit.  You take a few rough sketches on the back of a napkin, the nebulous promises of a sales person, and the direction from your architect and transform it into living breathing code.  It is not easy and requires a tremendous amount of skill and concentration.  This is why software developers crave solitude so much when doing their work because they need to get into a state of flow.  By being able to focus, a developer wants to get into a state of flow.  By being able to be in a state of flow a developer feels more productive and capable of getting work done.  This is why you see developers warring headphones and trying to block out the outside world when they are doing their work.  It is not because they are trying to be anti-social but rather block out distractions so they can get into a state of flow.

Unfortunately, there are many things in a contemporary office which discourage focus.  First, open office plans set up to encourage collaboration usually lead to distractions as people get involved in ancillary discussions, overhear personal conversations, and distracted by colleagues.  Next, demands from upper management and sales forces for reports and status updates means that instead of focusing on the tasks at hand they have to be managing correspondence with others.  Finally, social media and the web provide constant hours of distraction when someone should be focused on their work.

I think the biggest obstacle to focus is other individuals who cannot focus.  Usually these good folks wind up in leadership roles.  The inability of these people to set priorities or focus on one task then trickles down to their subordinates and you are left with a situation where people are juggling multiple tasks and getting none of them done with the quality and speed the business requires.  Often when confronted with the question, “What is the top priority?” these people will answer with “All of them.” This in my estimation is a recipe for mental illness and failure.

So what is a person supposed to do?  I have tried as best I can as I focus on my home business to set priorities and get them done.  First things first and last things never, as the old project management slogan says.  Next when confronted with an individual who can’t set priorities, I attempt to teach them how to set priorities.  This may explain why I have been rolled off so many projects over the years because people who hire consultants don’t like to be told they are managing projects incorrectly.  I also tell people who can’t set priorities that they abdicate their responsibility to me.  So I will do tasks in the order which I see fit.

Focus is not easy to achieve in a modern work place.  The physical conditions make it hard to focus.  The interference of e-mail and instant messages get in the way of concentration.  Finally, leaders who cannot set priorities make it impossible to focus.  This is why it is important for people like myself to create the conditions necessary to allow people to focus.  If we don’t then flow is impossible and high performance is a fantasy.

Until next time.

The Agile Dentist

You can learn a lot about agile
while you are at the dentists office.

I cannot think of a more helpless feeling than being in the dentist’s chair while getting a major procedure done.  You are medicated, filled with nitrous oxide but you are still conscious and feel pain; you just can’t do anything about it.  It was during this time of profound discomfort that something dawned on me.  Software developers can learn a lot from dentists.  This week I would like to expound on that topic.

I was receiving a root canal and feeling like I was in the middle of fifteen rounds with Mike Tyson.  My regular dentist was not in the office and so another was spending time using endodontic files on my mouth.  This is when it dawned on me.  My dental practice is a highly functioning team with each dentist able to do the same procedure on any other patient in the practice.  There were no specialists and it wasn't necessary for my dentist to be called in on her day off to get my root canal done.  Talk about cross functional.

Next, I had a hygienist numb my mouth and my doctor to the work.  I also noticed another person in the room that I never recognized before. This was a dental resident who held the suction tube and watched and learned while my dentist worked on my bad tooth.  This was pair programming because I could overhear the resident asking questions and providing instruments to the dentist while they worked on me.  It is one thing to pass tests in dental school. I am sure it is completely another thing when you are fiddling around with a real person’s mouth so this is how knowledge is passed from one generation to the next.

Finally, when my root canal was finished and when the dentist ground my tooth for a crown the resident took charge and finished the job.  I watched her as she weaned me from the nitrous oxide.  Then using a dental drill and resin she fashioned a crown to ware until the permanent version is put into place.  What I witnessed was a textbook example of how software developers should work together and I saw it at the dentist office.  Everyone was cross functional.  Senior team members were teamed up with junior members to mentor them and show them the ropes in the real world.  Finally, the junior members were trusted to do work without supervision.  It was a revelation.

So what I can take away from this experience is that software development does not have to be unpleasant like a root canal.  By using pair programming in the correct fashion, trusting junior developers to do the right thing and making sure there are plenty of opportunities to mentor you have the makings of a fantastic cross functional team.  This is good to know as I work toward building my own business that I have a good working model for an agile team.  Who knew that the dentist can be agile?

Until next time.

About That New Logo

The E₃ Logo

I wanted to take some time to reveal the branding of my new company.  I am like many people with a background in operations and technology; any time there is discussion of marketing it is greeted with sarcasm and ridicule.  This is understandable because we are more interested in making cool things than selling them.  However, as the time draws closer to the launch of the company, I had to start seriously thinking about what kind of image I was going to project to the public. 

I believe that the best kind of branding a company can have is its products and service to its customers.  I also know that a good company needs a logo that easily identifiable.  Facebook has a particular look and feel that gives a very different vibe from other social networking sites like Friendster.  The color of Coca Cola is red and is universally recognized. People have been poking the Pillsbury Dough Boy for decades.  If I am going to compete, then I need something to identify my company from the other software companies in the market. 

I asked a friend of mine who is a college undergraduate with aspirations of being a graphic designer to help.  After several rounds of revisions, my friend gave up and I was stuck with a bunch of half formed ideas.  This setback, made me realize that I had to take what I had to professional graphic arts firm recommended by a friend. After about three weeks of work and some revisions, we came up with the logo you see here.  I am pretty pleased with the work and think that it needs a little explanation. 

E₃ represents three major traits of the firm: Excellence, Expertise, and Energy.  My company will never be a perfect company or solution for every technology problem in the trucking or logistics industry but my company is committed to excellence in everything we do; from how we answer the phone to how we provide software to your company.  In terms of expertise, as president of this company I am a software engineer with over twelve years of experience building web based solutions for small and medium sized businesses.  I also have a Master’s of Science in Management.  Combined, I have the academic and professional credentials to help you solve your technology problems.  Finally, my company is about energy.  Logistics requires energy and stamina to be competitive and my company will be able to keep pace with the demands of the industry. 

The three is a subscript because it borrows from the syntax of chemistry.  Just as O₂ represents a molecule of oxygen and ammonia is NH₃; E₃ represents the merging of excellence, expertise and energy into a new compound which I hope will change the world.  The E is in a Serif type representing the traditions of trucking and logistics.  The three is san-serif to represent the modern 21^st century world of technology.

This symbol is superimposed on an oval of the Western Hemisphere because the world of technology and globalization is moving so quickly that globe is no longer round but distorted.  My company is a global company. With the expansion of NAFTA and other free trade agreements I feel the Western Hemisphere is going to become a giant market as North and South America combine to take on China and Europe. 

So, that is my company.  It is a mixture of excellence, expertise, and energy hoping to provide answers to your software questions. E₃ combines the traditions and practices of the past with the newest solutions for the future.  My goal is to become the dominant player in the Western Hemisphere for freight and logistics companies who wish to move their goods from Rio to Montreal.

You are welcome to come along for the ride, I look forward to showing you more in the next three weeks before E₃ launches.