No secrets on an agile team.

No secrets on a crap game or agile team.

I went to San Diego this week to talk about “Healthy Ownership,” with other agile professionals.  The experience got me out of the office and listening to others and their challenges making their workplaces better.  During the discussion, I recalled an old saying I learned when I worked as a dealer and pit boss at Harrah’s casino, “There are no secrets on a crap game.”  It occurs to me that wisdom can be applied to any agile team.

Working a crap game in progress, for the uninitiated, is confusing.  Dice are flying in the air and depending on the number they land hundreds or thousands of dollars can be won or lost.  It is a loud, frantic, and intense game of chance.  Since it is so fast, the dealers need to have incredible arithmetic skills, manual dexterity to make payments, the customer service skills of a butler, and the grace under pressure of a bomb disposal expert.  It was the most difficult job I ever had.

The reason dealers and pit bosses say, “There are no secrets on a crap game,” is things move so quickly on a crap table that bets are often made while the dice are in mid-air.  Only by shouting out your bet and having it confirmed by a dealer does it “count.”  If the dice bounce off a player’s arm on a crap game the other players will get angry and will often leave the table.  The superstitious behavior of gamblers encourages craps dealers to vocalize everything they do.  A dealer repeats back bets to the players.  A dealer often recites the payouts they are making and where those bets are located on the felt in front of them.  All this happens because the game needs to keep moving and no one wants to lose out on a bet.

In a world where agile teams have healthy ownership, the teams should exhibit three qualities.

1. Open Dialog.
2. Increased Empathy.
3. Collective Ownership.

For a crap game to be successful, open dialog needs to exist on the crew.  It is why everything is vocalized.  At casinos, my experience was crews were scheduled together so they learn to work together.  Finally, everyone on the crew is accountable if someone cheats or something goes horribly wrong.  It seems the casino business was into healthy ownership before agile professionals.

What does this mean for software development teams?  To achieve open dialog, the development team, scrum master, and product owner need to be in constant communication.  Stand up meetings need to be frank and to the point.  Product owners should listen in and make sure they can answer questions.  Scrum masters should facilitate discussion using the product backlog as the central hub of information.  Finally, developers should follow up on acceptance criteria to make sure what they are building is what the product owner needs.  If anyone is in doubt the should speak out.

To increase empathy on the team, the scrum master and product owner should share a work space.  It allows the scrum master and product owner to understand each other’s routine.  Using video conference equipment also helps.  It lets individuals see each other as real people instead of disembodied voices on a conference call.  Teams should work together in open spaces with areas for mob programming and rooms for privacy; I find both are necessary for the success and sanity of developers.  The most important piece is to make sure each member of the team understands the challenges and responsibility of the others so they may have empathy.

The final outcome of collective ownership is necessary for Healthy Ownership to thrive. It means the scrum master, product owner, and development team share equally the success and failure of each sprint.  I find this to be the most difficult outcome to achieve.  It requires highly skilled people to give up a little of their ego and make sacrifices for others.  To borrow a phrase from Benjamin Franklin, the agile team needs to hang together or all of them will hang separately.

To have healthy ownership an agile team needs; open dialog, increased empathy, and collective ownership.  The development team should not have any secrets just like a casino craps crew.  Following this model will create the healthy ownership which will help every team a success.

Until next time.

When a team fails.

Failure Stinks!

I continue to assert that software development is one of the most misunderstood professions in the business world.  Numerous executives think what we do is magic or do not understand the creative nature of the activity.  It is not like working on an assembly line or collecting accounts payable.  There is plenty of uncertainty and opportunities for failure.  As a scrum master and coach, you have to deal with the failure of your agile team along with the personal failures that inevitably crop up in your career.

The saying in the agile community is that you should “fail early and fail often,” because failure is a brutal and efficient means of learning.  The notion of failure conflicts with the “cult of success” preached by motivational speakers.  It also contradicts notions of winning promoted in sports journalism.  I believe the failures in my life and career have made me a better person.  I also feel these failures were necessary milestones on the road to the success I have had in my life.  Failure is painful, but it does put into perspective the ups and downs each of us have in this life.  

Part of the educational process is owning up to and taking responsibility for those failures.  When your team fails to deliver software on time, you have failed.  It is incumbent on you understand what you did wrong and how to avoid the same mistake in the future.  There are situations where you do not have much control, and you still are confronted with failure.  It is unfair and unjust, but accepting that position and learning how to deal with it next time may lead to success in the future.

The acceptance of failure also does something else; it wins the respect of others who have been through the same experience you have.  You have endured the same hardship as others and have accepted responsibility for your shortfalls.  If you blame others or do not assume liability for failure, it will undermine your credibility as a leader and destroy teamwork.  I witnessed this first hand and could see collective eyes rolling as this individual began to speak.

So as a scrum master and agile coach, accept failure and take responsibility for it.

Until next time.

Why I am learning TDD.

I am in the middle of a journey.  By day I am the scrum master for agile teams across two continents.  In the evenings, I am attempting to run a business and do development for that business.  It is not easy.  One of the hardest things about my job is that I have to improve my knowledge every 18 months or I will become stagnant.  A technology professional who does not continue to grow and develop, is someone of diminishing value.  This week, I would like to discuss that trend.

A software developer is a profession which is constantly learning and evolving.  When I began working as a software developer; Visual Basic 6 was a popular tool for enterprise applications.  Active X Data Objects were the means to connect to an SQL Server 7 database and ASP classic was just starting to supplant perl script for web development.  Today, all of those technologies are considered obsolete.  If I had not bothered to learn the newer technologies coming over my career I would be out of work today.  I had to learn Entity Framework, MVC, C#, and cascading style sheets otherwise I would be unemployable.

Fortunately, developers and other technology companies have numerous tools to retrain themselves with the new technologies as they come out.  There are educational video services, countless on-line tutorials, and numerous user groups around the United States to help software engineers keep their skills sharp and up to date.  Finally, developers are natural tinkerers and so they spend hours and even days learning to master new skills.

I am talking about this today because over the next few weeks I am going to start working on a project for work and at the same time I am going to attempt to master test driven development.  I know it is not going to be easy but I think with some hard work, I will be able to adequately author tests and help others understand why this is a good approach.  I have been putting off this learning for a long time so I hope it will make me a better scrum master and developer.

Until next time.

Why do we treat customers like users

It was a big week in technology.  Microsoft had a massive press conference to promote its new operating system.  E3 had a big technological breakthrough which will lead to new products which I will share more about in a later blog.  Finally, there was the state of the Union address which almost devolved into playground insults.  It was not a bad week.   What struck me most about the week was a tweet from Yahoo technology critic David Pogue he said the following,

Microsoft CEO Nadella just now: “We want users to love Windows.” You could start by not calling us “users.” http://t.co/kgtlt2Ux15
— David Pogue (@Pogue) January 21, 2015

The over-caffeinated pundit from Yahoo is right there is something wrong with software engineers because we refer to our customers and consumers as if they are drug addicts instead of full partners in the software experience.  This week I want to talk about that.

The term “user” has been around as long as I have been working as a software developer.  My suspicion is that I can trace its origins back to the early days of corporate computing.  Large Mainframe and AS/400 systems housed tremendous amounts of data centrally and the “operators” of these systems the network administrators and programmers allowed “users” to run programs to gather data.  Ever since the 1960’s, the term has stuck and I feel it poisons the relationship between those who make software and those who use it.

Since the first moon landings, the powerful computers which took us to another world can now conveniently fit into a contemporary smart phone.  Instead of mainframe systems, we have the internet and cloud based computing.  In addition, an entire generation has grown up swimming in technology.  Sadly the habits and attitudes have struggled to catch up.  Daily, I see developers use the term “users” to refer to the people who depend on the software we create.  Users are stupid, selfish, clueless, and careless in equal degrees and they are the bane of the life of a software engineer because they are constantly breaking their creations.

I understand this feeling.  I spend hours working on software trying to get it to work correctly and then someone comes along and breaks it with little or no effort.  It is part of the sense of pride and skill developers have which allow us too figure out how to bend technology to our will. When someone dismissively breaks that technology, it creates a spiral of rage inside me which is difficult for me to explain.  That software is my “baby” and for someone else to call it defective or ugly is a serious insult.

What we do not talk about is that the “users” are really not trying to break our creations or insult our intelligence.  They just want things which work.  They do not plug in a lamp worrying about amperage or voltage.  They just want to plug in a lamp and have it light the room.  Software is supposed to solve problems and help make the day go easier and faster.  They should not have to worry about out of memory exceptions or properly filling out forms.  They just need to use the software on their computer, mobile device and tablet.

They are not users of software; they are consumers and customers.  Those of us in the software profession need to remember that and treat these people accordingly.

Until next time.

The Insanity of Software

At times someone distills perfectly what it means to be a software developer.  This week Peter Welch posted the following article to Gizmodo and I strongly recommend it to my readers “Why a Job in Programming Is Absolute Hell”.  This week, I wanted to comment on this blog and try to let you know that while programming is hell; the trip is worth it if you can help customers try and solve their problems.

Welch’s thesis is that while software development does not require you to lift 50 pounds or dangle from a building while you wield together iron girders, it is filled with stress and insanity.  I can attest in my career that software is one of the few products we make in western civilization which is made completely by hand.  That said many of the people who build software see themselves as artists and craftsmen.  This is a recipe for mental illness and conflict.   Because no two software developers will build the same thing the same way, this means that the more software developers you have working on a project the more disagreements about how the work is going to get done.

I am going to postulate something known as Wisniowski’s theorem.  For every developer on a software team, the amount of disagreement increases by the power of the number of developers on the team.  Thus, a team of seven developers is two to the seventh power more likely to disagree about how to build something than a team of two developers.

To prevent this from spiraling out of control, scrum masters and project managers were created who were supposed to act as guides and leaders to prevent conflict from spiraling out of control and get work done on time.  This has created an entirely different set of problems because many project managers and scrum masters do not come from a technical background.  So they do not know how to mediate conflict in a technical team or even what questions to ask.  This means that developers become insubordinate and work around the project leadership to get work done.  By the time someone has realized what has happened, it is either too late or the developer has decided to switch jobs working someplace else.  If this sounds like madness, it is.

So what company to do?  Well many people purchase software in the hope of never having to figure out how it is constructed.  Others pay millions of dollars for consulting companies to build the software and hope that it works.  Finally, the truly brave hire developers and IT professionals and hope that they can keep the organization afloat.  I have lived it for over 15 years and I have to scars to show it.

This is why I founded E₃ systems.  I wanted to help businesses with low cost and low hassle solutions to fleet maintenance and inventory management.  Contact us today and we will tell you how.

Software development is filled with stress and insanity.  It has rewarded me with a modicum of independence and a middle class lifestyle but I know for a fact that there has to be a better way to practice my profession.  So enjoy that working software because someone had to go a little insane to make it a reality.

Until next time.

What is so great about 2014?

Looking forward to 2014 are you?

There are plenty of reasons to get excited about 2014.  A new year is a clean slate and it firers up an organization with the inspiration to come out fighting; like a punch drunk boxer.  This week on the blog I want to talk about some things we are looking forward to as an organization.

First, customer outreach; E₃ systems has been making efforts to reach out tour local community.  We were concentrating our products to a very narrow market.  This year, we will apply our products to any business that can use fleet management or inventory control software. Contact us today and ask how our systems can help your business today.

Next, we are graduating from Microsoft BizSpark. Three years ago someon I knew in the Chicagoland Application Lifecycle Management group told me about the BizSpark program. This company could not have started without the generous help and support.  I am looking forward to the time when I will be able to boast about our success to the tech media.  There is a place in the start-up world for Microsoft Technologies and we are proof.

Third, the continuing maturity of BootStrap and MVC means that the web is catching up to our vision.  When, I founded this organization I wanted to build web applications which worked on a variety of devices. Thanks to the Twitter BootStrap library, it is not possible for more people to make that a reality.  This is a good thing because it will be easier for my little start-up to find developer who understand what we are trying to accomplish.  We are also excited about the release of MVC5.  The embrace of BootStrap by Microsoft along with the security improvements and Web API means that the web is only going to get more interesting and we cannot wait to see that happen.

Next, Google has better unity between YouTube and Google+.  When Google+ first came out it was hard to get pages and YouTube channels to play nice with each other.  This made marketing and branding efforts a huge headache.  Fortunately, Google listen to its consumers and now pages and YouTube channels work together seamlessly.  Thanks Google and stay tuned as we make improvements to our YouTube channel.

Finally, the general economy is improving and with it the chance to grow our customer base.  The last three years have shown tremendous growth in web technology.  We at E₃ systems have stayed focused on those improvements to provide the best product for our customers.  With customers willing to spend on technology solutions we will see an uptick in customer and business.

So that is what we have to look forward to in 2014, we hope you will join us.

Until next time.

Patterns in the Code

Square Pegs is round holes. Could be design patterns

I spend a great deal of time reading other peoples code.  It is part of my day job as a Scrum Master.  It is also what I do as the president of E₃ systems.  It is a tedious task sometimes but I recommend it for every developer working today.  This week on the blog, I want to discuss code patterns and why they are important for any developer.

In the world of literature, there are countless critics and competing schools of literary thought.  Fortunately, the world of computer science does not have that problem.  The most important standard for software is that it works and that it meets the needs of customers.  This is changing as software becomes more complex and it has become more important to the operation of the business.  Standards cropped up thanks to this new reality and I think it has been a good thing for the industry.

Developers in many respects are like painters; they are creative, temperamental and a little crazy.  Ask two developers to write the same software with the same requirements, you will get code that is written very differently.  Multiply this by several hundred developers over three continents and you have a recipe for disaster.

Most coding standards are fairly common sense.  I personally like the standards from Microsoft regarding C#.  However, I am starting to see some troubling trends.  First, the Gang of Four, design patterns for Java are being used as a cudgel to punish self taught developers.  These design patterns have been taught in computer science classes the last ten years and the original book on the subject came out in 1994.  Today those patterns are used in numerous development languages.  A good developer with an understanding of the object oriented development doesn't need to use these patterns but some architects and a sizable minority think they should be the necessary grammar of development.

I strongly disagree with this position.  Gang of Four design patterns are a style of development not the last word on the subject.  To barrow from my friends in English and Communications theory, the Gang of Four represents a dialect of coding rather than the grammar.  Just like the formal language of a court room is different than the informal tome construction workers use on the job site.  There is a time and place for both and slavish devotion to design patterns make about as much sense as using a hammer to drive a wood screw.

Software developers often that they are artists but in the real world they are often being used like animators helping create large and complicated pieces of work with an almost infinite number of moving parts.  The Gang of Four design patterns are helpful but are being misused by a minority in the development community to judge the ability of other developers who do not understand these processes.

I am much more open to the SOLID programming approach which creates general guidelines for flexible code.  These guidelines make design patterns possible but not necessary.  If you use SOLID are more likely to write cleaner and easier to use code.  Furthermore, this approach instills good habits in both self-taught and classically trained developers.

A developer is his own worse critic.  I know that I look at code I worked on three years ago and cringe at my lack of technique.  I think I am a better developer now than I was when I started fifteen years ago.  I may not use design patterns but I think that I can create satisfying customer solutions.  In the end, that was why I wanted to be a programmer in the first place.

Until next time.