The Virtues of Agile: Focus

Focus Matters

This is the last of our series of articles about the virtues of Agile.  This week we cover the topic of focus.

Countless leadership books and seminars have said that focus is one of the most important skills a person or group can have if they want to succeed.  My favorite book on the subject incorporates science fiction into this scholarship.  For a software developer, focus is the key component to getting work done because it requires a tremendous amount of concentration to create software.  So of all the agile virtues, why have I saved focus for last?

This is because I strongly believe that focus comes about when the other four agile virtues are practiced.  I feel that it is not possible to have focus unless your teams have courage to get the job done, they respect each other and outsiders, are open to new ideas and challenges, and have commitment to get the job done.  The other four virtues act as lenses which generate the focus necessary to achieve goals.

I also feel this is easier said than done.  Today a person faces more distractions and obstacles to focus than any other period in contemporary business.  E-mail, instant messages, social media, and endless meetings seem to tug and pull at us like evil seagulls looking for a snack.  Add to the mix the office politics which accompanies an organization and you have a toxic stew of distractions.

This is why I like the scrum process so much.  A developer or scrum master can concentrate on a fixed goal for a fixed period.  It is easy to tell someone asking for additional features to say, “…that is a great idea we will put it into the backlog and then we can discuss it during sprint planning.”  Requests for favors go away because developers who work for me just direct those requests to the business owner and scrum master to prioritize.  This cuts down on “me to!” development which doesn’t add value but adds complexity to the project.

I am also discovering that focus needs to be reinforced on the team.  A scrum master should always say what the overall goal of the project is and how meeting sprint goals is just another land mark along the way.  A scrum master also should keep meetings to a minimum so that people who work under him or her can concentrate on what it takes to get the job done.  Finally, as a leader, the scrum master should pick a few attainable goals and stick with them.  This should create focus for the rest of the team.  If this strategy is good enough for the Secretary of the Navy then it is good enough for me.

It is easy to write about scrum.  It is much harder to actually do it in the real world.  I hope that this series has given you a chance to reflect on the agile virtues and how to use them in the real world. I look forward to sharing more of my acquired wisdom in the New Year.

Have a safe and sane New Year.

The Virtues of Agile: Commitment

Commitment is a strong bond

This is part four of five of our series of articles about the virtues of Agile.  This week we cover the topic of commitment.

Commitment is one of those things which is earned just like respect.  Sadly, our contemporary business culture makes it hard to make commitments which harms the success of organizations and makes it harder to for commitments to be made by line employees.  This creates situations where employees are “tuned out” of what is happening in the organization and who just go through the motions of serving the needs of the customers.  It is depressing and feels like being on a losing sports team.

As a scrum master and business leader, you need to commit to your team members and over time they may commit back to you.  There is no promise in this situation.  Some employees are just commitment phobic.  This is because they see work and the rest of the world as transactional.  They want to make sure that they have some “What’s in it for me?” moment.  So if they provide a service they get a compensation they feel they are due.

Commitment is different from this transactional model of viewing the world.  It is giving yourself over to something greater than yourself.  For the American armed forces, that this the “unit” which you belong.  For clergy, it is to your religious mission and for the entrepreneur it is to the business they founded.  This means that commitment requires sacrifices of time and behavior.  Many religious orders require vows of celibacy.  For the entrepreneur, it means long days of travel and work with no immediate pay off.

That said, commitment creates fiercely strong bonds between people who have made those commitments.  Military leaders work hard to develop these commitments to their troops because they know when shots are fired in anger they will have to count on those people to shoot back.  Business leaders need to work just as hard because while the decisions they make may not be life or death, they do effect the lives of the people who work for them.  Treating people like disposable tools to be replaced when they wear out is not going to generate commitment.  Something else has to be done.

Making sure that employees are constantly being trained and retrained to do their jobs better is one sign of commitment.  Another is providing them a game plan for how to improve their careers.  Nothing is worse for someone than stagnation and giving people a chance to grow and develop is an example of the organization making a commitment to them.  Business leaders can also get to know not only the employees but their families.  Asking about a daughter’s soccer game or looking at pictures of a Christmas recital can go a long way in showing employees you care and are committed to them.

There is no guaranteed pay off for this but when you need people to work overtime or deal with adversity a little commitment on your part could yield some commitment on theirs.

Have a Happy Christmas.

The Virtues of Agile: Openness

Everyone should feel safe in the Sauna

This is part three of five of our series of articles about the virtues of Agile.  This week we cover the topic of openness.

When I talk to business leaders about openness, I try to relate my experiences at my local YMCA as a metaphor.  As I have gotten older I, like so many of my peers, am trying to take better care of myself which means trips to the “Y” for some exercise.  It also means I get to sit in a hot tub and spend about a half hour in the sauna.  It is in the sauna where we can learn a lesson about openness. 

Each person in the sauna is naked or warring a towel.  Someone usually is reading a newspaper or magazine, someone else is chatting about the day’s events with a friend, and everyone mentions how warm it is in the sauna.  What does not happen is violence.  The reason why is there is no way to sneak a weapon into the sauna unless you are willing to do something extreme and uncomfortable.  The worst thing which can happen in the sauna is you are embarrassed about your shape or have a tattoo or piercing you might regret.  Everyone is forced to be a little open in the sauna.

An agile team and the organization should be like a sauna.  The low dry heat represents the pressure we face every day in the business world.  Everyone should be willing to be metaphorically undressed when in the hot house of business.  This means agendas are out in the open for everyone to see.  If someone does something embarrassing the others react to it with good natured respect.  If someone feels faint or passes out they get help and provide assistance.  In the sauna, we are all a bit naked and tired.  

This does not mean you have to be totally open.  Confidential information, like salaries and trade secrets, do not have to be discussed in the sauna if someone does not want to discuss it.  Sometimes, information needs to be parceled out in small bites and that too is acceptable.  What is not acceptable is outright deceit or lying to have advantage over the others. 

This is why openness is difficult to cultivate in an agile team.  For years developers and executives have been trained that “knowledge is power” so they tend to hoard information.  In an open team, the rookie developer would know that the old hand on the team has not worked with LINQ statements over his career and might need help.  The veteran may know the business and why a certain approach is being used to fix a problem and should share that with junior developers instead of having them hacking away at code in the dark. 

Openness begins with a scrum master who lets the team know what is going on each day in the stand up and during the course of the day.  They help the developers stay focused by avoiding distractions and having them concentrate on sprint goals.  They also have to good sense to look the other way when open of the team members metaphorically drops his towel and makes themselves vulnerable.  I also make a point about joking about my lack of muscle tone to keep the team loose. 

Openness is about being safe with in your own skin and when exposed to the skin of others who are in the same situation you are in.  Without this virtue team collaboration is partial because everyone will be concerned about agendas, possible threats to their career, and lack of safety. 

Until next time.

The Virtues of Agile: Respect

This is part two of five of our series of articles about the virtues of Agile.  This week we cover the topic of respect.

Of all the values of Agile, I think that respect is the most difficult to define.  I believe that this is because it is the one virtues based on emotion more than any other.  You cannot force a person to respect another person. It is a situation which develops over time when two people work together.  In high pressure atmospheres, like technology, respect can also be fleeting.  The person you respect today could be a colossal impediment tomorrow.  It is a difficult quality to cultivate and develop among professionals.

In my experience, it is also difficult to give respect to others because for most of my life as a professional respect was something which was earned.  Someone did not receive respect from you until they earned it by helping you or accomplishing something worthy of respect.  I remember this being the case during my years in debate and I also saw it in the realm of technology.  People who understood how to implement technological solutions were elevated above others and were granted respect by junior developers.

Since I have been a scrum master for the last year, I have seen that respect is not something earned from others but something you give others and they repay in back to you.  Respect is a virtuous cycle which reinforces itself with in the team.  This is not just about knowing the names of the people on your team.  It is about knowing if they have children and what they are doing.  It is about giving time off for them to attend Christmas programs.  It is also just shutting up and listening to people.

This is contrary to much of the leadership advice we receive from public figures like Donald Trump or Kevin Trudeau being leader is not so much about being in charge but being a servant.  A leader serves the people he is supposed to in charge because the only way that they succeed is by helping others instead of being a selfish jerk.  It also means that you are going to have to swallow some pride and learn to work with others who seem impossible.

It has become obvious to me that most of my problem employees are not really problems per say but they are having problems with their job and it is my duty to fix them.  A developer accustomed to cut and paste programming was floundering, after a few training courses and working with MVC5 and Typescript they are a dependable member of my team.  In addition, he volunteers to help in situations I was not expecting to contribute.  It happened because our relationship moved away from conflict about him not hitting sprint goals to him actively participating in the team.

I am not perfect on this front.  I struggle with names on a regular basis and I have to suppress my more narcissistic tendencies.  Some people I have a very difficult time respecting because they have toxic personalities or are self-centered but I try and hope that a little dose of respect will go a long way.  Respect is not easy but if you truly want to have it on your team them you are going to have to provide it to you team members.

Until next time.

The Virtues of Agile: Courage

Agile requires courage

Beginning this week and until after New Years the blog with be covering the five virtues of agile development.  This is part 1 of five talking about courage.

As a scrum master and software professional we spend a great deal of time talking about how to “do” agile but we really do not talk about the values that act as the foundations of agile development.  I wanted to take some time at the end of the year to discuss these founding virtues of agile.  I suspect that it is easy for technical professionals to talk about the steps they need to follow rather than the feelings they need to have in order to do the job with a sense of pride.  Speaking from experience, it is very hard for software people to talk about feeling because we use reason, logic, and engineering principles to do our job.  The funny thing is that we feel stress, we have relationship problems when work goes bad, and we feel rage when treated like short order cooks instead of technical professionals.

According to Dictionary.com courage has two definitions; first, the ability to do something that frightens one and finally, strength in the face of pain or grief.  I would like to add that I consider courage to be the ability to do the right thing when no one is looking and the hard thing when everyone is watching.  This means that people on a software development team and within an organization need to be empowered to do the right thing when the situation calls for it.  Often with people worried about promotions and job security, when faced with a difficult choice they freeze and do nothing.   I feel this happens because an atmosphere of fear is created within an organization in order to keep people in line.

Melanie Greenberg in psychology today categorized six traits for courage; they are:

• Feeling Fear Yet Choosing to Act
• Following your Heart
• Persevering in the Face of Adversity
• Standing up for what is Right
• Expanding Your Horizons; Letting Go of the Familiar
• Facing Suffering with Dignity or Faith.

I really cannot think of a better discussion of what it takes to have more courage.

The expansion of courage begins with senior leadership.  It starts with allowing people to make decisions and then coaching them to make better decisions after the fact.  It involves coaching people to take smart calculated risks.  It involves trusting people to make choices.  It means that when a wrong decision is made you find out why it was done and then help correct that person so that they do not make a poor decision again.  It also means that when you are confronted with a choice you make a brave decision because nothing undermines courage among a team than a leader who is cowardly.

As a technology leader, I struggle with courage all the time.  I take inspiration from great leaders like Richard Winters, Colin Powell, Harvey Milk, Norman Schwarzkopf, and Adlai Stevenson.  I also count on the support and help of the people around me to do the best I can.  I am not perfect and falter like everyone else but I try to exhibit courage in my daily life.  I owe it to my agile team, the organization I work for, and the customers who depend on me.

Until next time.

Work to do in the shadows.

Change takes place when we work together in the shadows

Illness and the grey rainy weather of November in Chicago have put in a philosophical mood.  I have been contemplating a few things.  Today, according the United State Census Bureau there are 7.2 million people on the planet earth.  That is twice the population of when I entered this world pink and helpless in 1968.  How have we been able to double the world’s population without famine, war, and the complete collapse of civilization?  It struck me that what keeps the world civilized are many people working quietly in the shadows to keep it that way.  I am one of them and I am sure some of you are too.

When I was born the big intellectual book of the time was Paul R, and Anne Ehrilch’s “The Population Bomb.”  The book argued convincingly that as world population grew it would be harder to feed and provide for additional people.  What the authors did not count on were the smarts of scientists, engineers, and common people like me to solve problems.  The green revolution spread through the developed and third world during the 1950’s and 1960’s.  This gave the world enough to eat.  What started the green revolution?  Scientists and farmers who realized there needed to be better yield out of crops and figured out a way to do it.

During the 1940’s the biggest killer of children in the United States was polo.  Countless children died or were forced to breathe with iron lungs.  The March of Dimes was founded because they were looking for a means to wipe out polo.  It took huge efforts from science and government but the first vaccines began to appear in 1952 and polo was eradicated in the United States. 

The March of Dimes continues its efforts today but instead of polo they have focused on birth defects.  Again to the rescue, stubborn and determined people who worked quietly doing the necessary work.  People like Clair Patterson who determined the age of the earth but also found the link between leaded gasoline and lead poisoning in humans.  With opposition from the petroleum industry Clair proved beyond a shadow of a doubt that lead levels were rising.  With the help of congress and international treaties, leaded gasoline was banned.  As the level of lead in the atmosphere declined, we also saw the decrease in birth defects and problems caused by lead poisoning worldwide.

Again not glamorous work, but necessary to make the 7.2 million people of earth happy and healthy.  It is work being done be civil engineers to make sure that sewers keep our drinking water safe.  It is the work being done by infectious disease specialists tracking bird flu and Ebola.  This is the work of software developers helping build logistics systems which move goods and services across the country. It is doctors, janitors, clerks, nurses, and ordinary people making hospitals not only more effective but more efficient.

Some of you may be asking, where does agile come in to this picture.  For too long, the world of business has been dominated by too many damaged, neurotic, and just plain mean people perpetuating a cycle of abuse kept alive by the threat to take away living wages.  It is why investment bankers didn't leave their steakhouses and join the occupy Wall Street movement.  Agile and the agile movement, which I am proud to be a part of is not a revolution but rather an evolution of the business world so that it is more humane, sustainable, and satisfying to the people doing the work.  In other words, work is changing from toil serving unnamed shareholders or executives to a craft where people can take pride in what they do.  We have so much work to do but in just thirteen years since the creation of the Agile Manifesto the face of business is changing more of them are “doing” agile.  It is my hope that someday soon they will “be” agile as well.

This is because people, like me, are quietly working in the shadows to make it happen.  Please join me.

Until next time.

Expectations in a Age of Magic

Sometimes it is rocket science.

One of the funniest social criticism ever made came from comedian Louis CK.  In his discussion with late night host Conan O’Brien, he talks about how fantastic technology has become and no one is happy with it.  I am reminded of Arthur C. Clarke’s three laws of predicting the future the most famous being, “Any sufficiently advance technology is indistinguishable from magic.”  This week on the blog I wanted to discuss expectation setting and getting your business partners to have realistic expectations about technology.

I was thinking about this topic this week as I was watching the coverage of the Rosetta space probe and it placing a lander on the comet.  The technical achievement was astounding.  Over ten years and one and a half billion euros we not only got to see the surface of a comet but we actually landed an object the size of a consumer dishwasher on the surface.  What made this more satisfying was how the science press and the main stream media covered the event. Both seem to admit that success or failure, the European Space Agency’s did the best it could do and that whatever happened it was a big achievement.

Wryly, I joked on LinkedIn that I was looking forward to some of my business partners saying, “If we can land something on a comet why can’t we do X with the web site.”   My mild cynicism hit a nerve because people began to comment and tweet me saying they were expecting similar answers.  This is when it hit me.  Numerous people who work with technology really do not understand how that technology works.  They just take it for granted.  It really is “indistinguishable from magic.”  They can get the weather forecast in Toronto, schedule a truck to deliver products to the city and electronically communicate with Canadian customs to avoid the truck being stopped at the border.  They do it with technologies like the internet, EDI, and Java but they really do not understand how these technologies work.  They just take it for granted that they do.

This is when more knowledgeable people need to step in with expectations.  We understand the amount of work which needs to be done and the difficulty of the tasks.  We also understand that most technology problems in a contemporary business are not technology problems.  They are people problems which could be better solved by individuals working better together.  So when someone says, I would love to have “X” on the web site; ask the hard questions and find out if these improvements are necessary.  Ask about technical debt and why the organization tolerates it.

It is the responsibility of technical professionals to act like the engineers we were trained to be rather than magicians carefully guarding our secrets.  Business partners need to understand the trade-offs which are made every day to keep the organization running.  A new feature for the billing system or web site doesn't pop into existence from the mind of the business owner.  It requires work from developers and quality specialists.  It needs to be accepted by the business.  Finally, it has to be accepted by consumers.

This is not an easy road but it is certainly easier than landing a probe on a comet.

Until next time.

Danger signals for the Scrum Master

Stress is not sexy.

There is nothing glamorous or exciting about being exhausted.  This week on the blog I wanted to talk about some things you need to pay attention too when they come up.

You want to throw things at the office: We toss paper into the waste paper basket.  But what I am talking about is much more serious and frightening.  I was on a conference call after less than six hours of sleep during 72 hours of production issues.  I picked up my mouse and wanted to throw it into my monitor.  I did the next best thing which was walk away from my desk.

You want to spend your time insulting others rather than helping them: Lack of sleep and the pressure of the job can transform a saint into a green hulking rage monster.  If you find yourself wanting to insult your staff or belittle them you need a break.  Your direct reports should not have to suffer because you are too tired to think straight.

You let things go you normally would not allow:  When someone says, “I don’t care” it usually means that they do not have the energy to pay attention to the details.  That is a recipe for failure and a bigger accident to follow.

Your staff starts asking you if you are ok:  Being a manager means warring a “mask of command.”  If you drop that mask and your staff starts seriously wondering if you are up to the job; you may need to take a step back.

You are not sleeping: If you can’t lay down and get some sleep at the end of the day.  This is a serious danger sign.  You need to finish up what you are working on and try to uncoil because not sleeping can create situations similar to being intoxicated.

You can’t focus: Leadership and technology require concentration.  If you can’t concentrate you are sunk.  Taking time off to step away from the project or just the office is going to do you a great deal of good.

Each of these things happened to me this week and I knew the danger signs.  I told my boss and he was good enough to let me work from home.  It was very positive and helped me get through a very rough period.  It also protected my staff.  Life is too short to work for bosses who are struggling to keep it together.  

Until next time.

The Power of the Pivot

Sometimes you have to stop getting punched in
 the face to realize you need to make a change.

The life of a Scrum Master or Entrepreneur is filled with uncertainty.  Today’s sure thing becomes tomorrow’s dead end.  This is why I wanted to devote to this week’s blog to the power of being flexible.  In the parlance of Silicon Valley start-ups, pivoting is powerful.

According the Agile manifesto, responding to change is more important than following a plan.  This seems counter-intuitive at first but when you work in the software business for a while you understand why agile people say this.  I can’t remember how many times I have been involved in a course of action is a software project where I have been futility swimming upstream.  A slight course correction or change of approach would have sped up the project and led to success.  Unfortunately, project flexibility was not built into the project and as a developer I was doomed to work on a failing project.

If leadership was more flexible and willing to make changes in light of the current situation the chance of success might increase.  This is where we get the term pivot from.  I learned about it from a fantastic article from Vanity Fair about the purchase of Instagram by Facebook.  I highly recommend the article to anyone willing to learn about adopting to change.  In summary, Instagram’s CEO Kevin Systrom had numerous bouts of failure and frustration.  It was only after he pivoted his firm toward photography and filtering that he was able to find the success he was seeking.

I remember reading this article on a plan ride home from a corporate off site meeting.  I witnessed the new organizational chart and saw five people named project managers who I had personally trained to use Team Foundation Server.  I also noticed that I was not going to lead a software team.  I felt humiliated and my career was at a dead end.  I was filled with anger and frustration.  Something had to give, and it was clear to me that it would have to be my career at my old firm.  I got together with a few of my mentors in the agile community including Alan Dayley and they gave me the support and encouragement which I needed.  Within a month I had changed jobs and become an architect and scrum master at another company.  It is one of the few times in my career I can look back and say I did the right thing.

So my lesson is that sometimes you need to pivot to be successful. Blindly following a plan will lead to nothing be frustration and misery.  If something isn’t working try something else.  We invest too much into the sunk costs of our lives.  By pivoting or responding to change instead of following a plan, we gain a fraction of our lives back and learn to find success.  It is not as neat and orderly as we would like but in an uncertain world it is the only thing we have.

Until next time.

We need more women in tech.

Women are just as good as men in tech.

I have spent over fifteen years in the technology business as a consumer, developer and scrum master. One constant during my career is that there are not enough women working in technology. Numerous articles have been written on the subject and plenty of initiatives are bubbling up around the web to teach women to code.  Still, I want to address a few of the myths I have heard about women and technology which need to be discredited.

1)Women are not logical enough to code.

This is false.  The American Psychological Association states, “…gender differences in math achievement are largely due to cultural and environment factors” (emphasis mine).  So given and equal level of training women and men are equally good at math and by default logic.

2)Women cannot work the log hours required of programmers.

This is a cop out for two reasons.  First, working more hours does not guarantee better work.  According to the Harvard Business Review the more hours a person works the less productive they become.  Second, long hours are often a failure of project planning and business leadership. Individual developers should not have to pay the price for bad planning.

The above said, working extra hours and being involved in crunch time is a perverse badge of honor.  I like it when the Netizen Corporation Blog says, “This is a representation of failure rather than commitment.”

Having women in the office particularly women with families lives tempers this desire to work insane hours as a form of perverse competition.  When you have lives outside of work it tends to make that labor more productive.

3)Women hurt the teamwork of the development crew.

Study after study has shown diversity of gender, race and religion yields better decision making.  If anything software development is about making decisions.  People do feel discomfort when thrown together with groups they are unfamiliar but one they get over that discomfort their performance improves.

I have experienced first-hand the change which takes place when women are added to a development team.  Jokes about alcohol consumption and romantic conquests go way down.  The men on the team care more about their hygiene and appearance.  Everyone becomes more polite and professional with each other.  Finally, disagreements are worked out in a more civil fashion.  It is not perfect but it is much better than working on all male teams.

4)Women are just not as knowledgeable.

There are plenty of women in technology who have fantastic skills.  Marissa Mayer did not graduate from Stanford and become and executive at Google because of her good looks.  She was a smart and capable engineer who also brought to the table a keen sense of design and a fanatical devotion to metrics.

From a more personal perspective, Angela Dugan author of the “The TFS Whisperer” has become a role-model and big sister of sorts.  She introduced me to TFS, Agile, and better development methods.  She leads the Chicago ALM group and has a profoundly strong reputation among the development community around Chicago.  I have known Angela for over five years and I am better technologist because of it.

These two women are just some of the people I know who bring a sense of craft and commitment to their technical skills.  This just confirms to me that you do not need to have a UNIX beard in order to be knowledgeable.

Technology needs more women but some of these myths I have attempted to discredit have gotten in the way.  If this situation is going to improve men and women are going to have to step forward and quash these faux myths of male programming superiority.  Otherwise we will continue to be stuck in the same destructive patterns we see today in the world of development.

Until next time.

It is always something

It is always something.  Being a scrum master
requires a good sense of humor and great deal of self-reflection.

Like many people from Generation X I did much of my growing up during the 1970’s and 1980’s.  One of my favorite celebrities of this period was comedian Gilda Radner from the original Saturday Night Live cast.  She was taken from us far too soon by cancer but she was inspirational in how she lived her life.  She used to say, “It’s always something” with a wry smile and discuss the absurdities of life.  It became the title of her autobiography and for those of us who work as scrum masters we should take it as our personal mantra.

Scrum Masters are confronted daily with numerous problems and have to address them.  In the agile world we call them “impediments” but the reality is they are problems making it difficult for the team to meet its sprint goals. These problems could be developers not getting along or they could be systematic having upper management buy into the process.  It is late nights with developers burning the midnight oil and early mornings taking phone calls with off shore teams.  It is being positive when you have no logical reason and always coaching others to be better.

I have wanted to be a scrum master for over four years and I leaped at the chance when it came along.  Now that I have become one my early enthusiasm has transformed into quiet stoicism.  Each day my team is judged on the software we ship and the value which we provide for the business.  There is always a daily crisis of some sort.  There are millions of dollars in revenue at stake and never enough time to do things.  Under these constraints, it takes a good scrum master to get his team to perform.  I am working toward being a good scrum master.

Until next time.

Do Not Kiss the Cobra.

Incentive programs are just as
 misinformed as kissing a cobra.

As a leader you are faced with countless decisions.  One of those decisions is how you create constructive incentives for your team.  This week on the blog I would like to talk about one of the most dangerous traps you can get into as a budding leader.  The Cobra Effect.

The cobra effect is documented around the internet but in short is a classic example of the rule of unintended consequences.  Simply put, when you put an incentive out to guide the behavior of co-workers or subordinates you will find they will game the system to maximize the incentive for their own personal interests.  This was documented when the English ruled India as a colony.  A local governor offered a bounty to reduce the number of cobras in the city of Delhi.  It worked too well and the locals started breading cobras to kill them and collect the reward.  This bit of capitalism got the governor to cancel the bounty.  In response, the cobra breeders released their worthless snakes out onto the streets.  The net effect was an increase in the cobra population of Delhi.

As a scrum master or leader you can run into the cobra effect at any time.  For instance, if you want to increase the velocity of a team the team members could inflate their estimates making it look like they are doing more work than actually doing it.  My favorite example comes from the comic Dilbert where the pointy haired boss offers to provide bonuses for developers who fix bugs.  The developers use this as an incentive to write buggy software to increase their compensation.  

The short answer is that incentives are not a good tool for improving performance.  People will change their behavior temporarily in order to meet the incentive goals and then when the incentive goes away they will switch back.  This means that developers and business people will take shortcuts instead of doing the job the way it is supposed to be done.  Long range goals are sacrificed for short term incentive gains.  I also feel that quality suffers.  

So when coming up with incentives for your development team and business, take a pause and understand that you are inviting a snakebite from the Cobra effect.  

Until next time.

Self Organization and Boundaries

Boundaries mater in Agile

Being a Scrum Master is hard work.  You spend a lot of your time helping others and many times wind up acting as a therapist for the people on your team.  You massage egos, help with nagging insecurities and keep fear and uncertainty at bay.  It is the most rewarding and the most frustrating things you can do.  The most interesting thing I have found over the last few years is it also requires some firm leadership and boundaries.  This week I would like to talk about that discovery.

As I usually do, I spend a great deal of time surfing the web learning about technology and gathering up new ideas to lead my team when I stumbled on to an article in Slate.  Laura Smith in her article “Why I Regret Being a Nice Boss,” spoke about her experiences running a coffee shop in Washington D.C. What struck me about the article was the realization that as a leader some things were just not negotiable.  Employees were expected to be on time and each employee had a set number of minutes for break time.  Those who violated these non-negotiable rules were written up and eventually managed out of the firm.

This made me think about agile principle number eleven, “The best architectures, requirements, and designs emerge from self-organizing teams.”  How can a leader set non-negotiable terms and still allow a team to self-organize?  This is when I realized that when a business or leader sets something as non-negotiable they are really setting boundaries.  Once a team understands what the boundaries are they can organize within them.  For example, a sprint is always a fixed length.  This means all work committed to by the team must be finished by the end of the sprint.  How that work is divided up and managed by the team is up to the team but the work must be finished and that is non-negotiable.

During a sprint the team decides what a good definition of done is.  For the teams I work on, it is the following; unit tests written, code which compiles, code checked into source control, and code pushed to our development environment.  If this this definition is not met then the user story is not “done” and the developers have to go back and finish the work.  This creates some tension with meeting all the sprint goals but it has saved my team numerous hours of headache over the months.

Once the sprint is done, we have used our retrospective to tweak the definition of done for the next sprint to make sure that we are improving.  This keeps with agile principle number twelve, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts behavior accordingly.”

So being a firm, fair therapist is what you should strive for as a servant leader of your software development team.  By setting boundaries, you give your team a safe place to experiment and thrive.  You also create an environment where everyone knows what is expected and how they can succeed.  This isn't always the nice approach but it will make everyone feel better at the end of the day.

Until next time.

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. 

The Power of No

Sometimes it just needs to be said.

This week I wanted to discuss something which is pretty important to every business person and entrepreneur I know.  For years we have been taught the importance of yes, getting other people to say yes, saying yes to the deal, and making sure you say yes to any reasonable request.  People who say no are not team players or willing to succeed.  The reality is that saying no is as just as important to success as saying yes.

Daily we read stories about work life balance and what it takes to be successful.  A common theme in many of these articles is the ability to say yes.  It is easy to see why coaches and mentors say this.  Saying yes is easy; doing what you promised when you say yes is hard.  This way it is easier to make a promise and break it because you can always ask for forgiveness.  Business is filled with plenty of people who can make promises but cannot fulfill them.  This situation means that as a business person or leader you spend a majority of your time in a constant state of distrust because you do not know who is telling the truth and who is just saying what you want to hear.  It is madness.

This is why “no” is so powerful.  Because it cuts through the phoniness of typical business interactions and lets people know what is really going on.  The word “no” builds trust because they can honestly engage in pragmatic discussions about what can and can’t be done. I am not advocating being negative or reflexively saying no all the time but the judicious use of the word no can make your life much easier.

Let me give you a few examples:

• Can you stay late tonight – “No, my daughter is playing softball tonight.  Can I come in early tomorrow or work on this after the game”
• I need this software by X – “No we do not have enough developers or time to build all those features.”
• Can you build this software for a fixed bid – “No, this does not compensate properly for the work we do.  Feel free to take your chances with someone else”
• Can you take an extra project – “No, I am flattered but I want to devote my attention to these other projects and make them successful.  I might not give this new project the attention it deserves”

In each of those examples, saying no sets limits.  You are not being negative or hostile you are just setting limits to prevent others from exploiting your desire to help them.  There are plenty of people in business who don’t respect limits and those are people who have high turn-over and bad work environments.  By outlining limits you act as a warning sign to people in authority.  They have to hire more people or redo budgets rather than taking undo advantage of people working for them.  It also prevents vendors or clients from making demands which might cost you money.

So the next time you are tempted to say yes, take a deep breath and remember the power of no.  It may just save you time, money and aggravation.

Until next time.

Three reasons why I love Agile

Agile is like dance for geeky people.

It has been a challenging week but I wanted to take some time to update the blog this week. I have spent over fifteen years of my career as a software developer and project manager.  I have spent the last five years working in the growing field of Agile Software development.  I have been an eager convert to Agile and Scrum for the last five years for a reason.  Agile is the best way to build software.

Unlike many things that are currently manufactured in the 21st century, software is made by hand by creative, highly trained, and eccentric individuals known as software developers.  Ask them to build swing with a tire and a stretch of rope and they will argue about what knots to use and what kind of rope is acceptable.  This means that simple tasks like saving address information into a database or asking a person to log on to a web page becomes a colossal debate.  Agile eliminates this because it forces a software development team to focus on what needs to be done to complete the sprint.  Debate is curtailed when confronted with a deadline.

Next, the people who pay for software often don’t know what they want so developers spend countless months of toil working on software only to be told their labor is worthless because they did not build what the customer wanted.  Agile stops that from happening because the iterative process means the people paying for the software get to see it every step of its production so they get way they want.

Finally, Agile exposes who is doing the work and who is wasting everyone’s time and money.  Engineers and developers have to produce results and hiding in plain sight behind jargon and techno babble will not work.  Either the team succeeds or it fails to meet sprint goals and no amount of excuses will change that result.  It is that environment of honesty which makes going into the office more pleasurable.

So because agile is a more honest environment, gets the customer involved in the development process, and keeps software developers focused, it is the superior method of building software.  This is why I am a big proponent of it and why I will continue to promote it like a zealous Jesuit.  That is my story and I am sticking to it.

Until next time.