Don't be a Mad Hatter Agile Shop!

Delivery of software is not madness.

Becoming a scrum master is not hard. Professional certification takes two days of classroom training and a simple test makes sure you understood the information.  The real work happens when you are beginning your servant leadership of a software development project.  You wear multiple hats.  Somedays, a scrum master is a therapist.  On other days, they act as a cheerleader and on others they are a technical consultant.  It is a challenging career.  One of the things which get lost is the purpose of agile and scrum; is the team is responsible for delivering software.  Today, I want to discuss software delivery.

The Agile Manifesto is very clear about delivering software.  An agilest prefers working software over comprehensive documentation.  When the manifesto says “working software,” it means software in production used by customers.  Anything which does not meet this goal is not working software.

Over my career, I have had numerous conversations about when work is done.  Many of these conversations sound like sections of Lewis Caroll’s “Alice in Wonderland.”  I had a developer tell me with a straight face the code was finished, but the code did not compile.  I had another developer tell me they did not need to write unit tests before checking in code to source control.  The worst moment in software development is when a developer says, “It works on my machine, so it is done.”

None of these situations qualify as working software.  As a scrum master, you need to ensure that everyone understands what working software is.  In the agile community, we call what constitutes working software as a "definition of done."  In the medical community, successful treatment of illness is called the "standard of care."  I prefer to use the medical term standard of care when talking about working software.  It is a set of necessary and sufficient conditions.  Here is my formulation of what a good standard of care for web development is:

1. Does the software compile?
2. Does the software have a unit test to prove it is doing what it is supposed to do?
3. Does the software exist in a source control environment so that others can inspect and edit it?
4. Does the software work on a staging or test environment?
5. Does the business approve of the software delivered?
6. Does the software work in a production environment?
7. Are customers using the software?

We do not have working software if these conditions are missing.

I understand the standard of care seems extreme to some but think of all the steps you have to go through when you have surgery.  The nurses are required to count every piece of gauze, and surgical instrument used. The last thing a patient needs is a piece of gauze left in their body to be an environment for infection.  Likewise, in the software world, you do not want to deploy code which is not unit tested because it will be harder to debug and troubleshoot when something goes wrong.

Software not being used by the customer in production is not working software, and any good scrum master and product owner must make sure that happens.  If not, you are just pretending to be agile.

Until next time.

How to write a good user story.

Tell a story and get work done. 

When you are working as a scrum master or agile coach, your biggest challenge is getting others to understand the concepts of agile.  It is like teaching young children to read.  The concepts seem natural to an adult, but to a six-year-old, it is an alien skill to master.  It occurred to me this week I have written numerous blogs about the different aspects of agile development, but I have never written a blog about authoring user stories.  Today, I want to change that oversight.

Let me begin by saying I am sharing with you how I teach others to write stories.  Each coach and each environment is different.  Feel free to treat this blog as an informed suggestion of how you can do things at your organization.

In the early days of agile, a user story could fit on a post-it note.  Team members would see the story ask the product owner for some discussion about what to do and then the work would get done.  The early approach assumed the development team was in the same room and the product owner was always available to answer questions.  Today with team members scattered around the globe, product owners focusing on customers, and countless tools to track work items, it is not realistic to rely on just post-it notes.  Regardless of what system you use to track user stories, the first thing you should do is boil the work down to one sentence.  I use the following format.

As X I want/Need Y because of Z.

The template is easy to follow and works in most situations.  Here are two examples.

Example #1 – As a sales manager I want the background of the shopping cart page to be blue because it reduces the number of dropped shopping carts.

Example #2 – As a user, I would like the website to save my customer information because I do not want to retype information. 

In both examples, the subject of the sentence is the person who needs the work done.  The predicate of the sentence is the actual work.  The modifying clause is a credible reason why the work needs to get done.  The sentence should satisfy the Who, What, Where and Why of the work.  It is up to the developers to provide a credible answer to When the work gets done.

Once you have authored a user story, it needs acceptance criteria.  Acceptance criteria are important because it removes misunderstanding between a member of the development team and the product owner.  Unlike waterfall techniques which demand long and confusing narratives, I show product owners the Gherkin or Given, When, Then (GWT) formatting of writing acceptance criteria.

Given: I am registered user of the website
When: I check out my shopping cart
Then: My billing information is retrieved
And: My shipping information is retrieved.

Notice the GWT does not say how to do the work; it just says what the product owner expects the development team to deliver.  The team could use session variables, cache objects, or cookies to do the work.  It does not matter.

A user story should look like this in the work item tracking system.

23 – Save shipping and billing info
As a user, I would like the website to save my customer information because I do not want to retype information.
23.01 
Given: I am registered user of the website
When: I check out my shopping cart
Then: My billing information is retrieved
And: My shipping information is retrieved.

The number is usually automatically generated by the item tracking system.  I use a ##.0# numbering system for acceptance criteria for clarity, and I provide a title for stories.  During stand-up meetings, developers refer to stories by saying, “I am working on number 23 save shipping and billing info.”

I hope this is a good starting point for how to write user stories.  With practice, it will become natural just like reading.

Until next time.

That awkward talk about scaling

Portrait of a Scrum
Master as a young man.

When the signatories of the agile manifesto got together sixteen years ago, they had no idea what they created would be the basis for a reformation in the business community. I have been part of the agile movement since 2009.  I am a short timer.  During my brief agile practice, I have noticed a trend.  Software projects are getting bigger, and it is becoming increasingly difficult to lead these projects.  This week I want to talk about scaling agile as software eats the world.

When I first learned about agile and scrum, I felt like the apostle Paul on the road back from Damascus.  It was like being struck by lighting and seeing the world for the first time.  The team did work in sustainable chunks.  Stakeholders would receive rapid feedback about how the project was going.  If something was wrong, it could be escalated quickly up the chain of command.  The ability to create software would become more sane and human.

I was deeply deluded.  I did not count on the ingenuity of my fellow software developers to avoid work.  I was blind to the inertia which exists in the modern corporation which rejects new approaches to solving problems.  Finally, executives and financial professionals see agile as a threat because it undermines their need for command and control.  Confronted with these realities, agile and scrum became a means to help small teams ship software promptly.  As individual groups became successful, management began paying attention.  Soon entire Agile consulting teams sprang up offering Scrum Masters and developers who could rapidly bring software to life.  For three years, everything was going well, until enterprise software application attempted to be agile.  It was 2012 and agile hit awkward puberty.

Software teams would be sprinting at different cadences.  Some teams would be sprinting every three weeks while others would be on a two-week cycle.  Network teams were not even sprinting and would treat requests on a first in first out basis.  Finally, the marketing team would be making promises which others would have to keep.  I and others would ask, how do you scale Agile across multiple groups and projects with hundreds or thousands of developers?

The answer has fractured the agile world into three camps; scaling with scrum, SAFe, and LeSS.  I have received formal training in scaling with Scrum and SAFe.  I am looking forward to attending LeSS training in the new year.  Each camp is involved in a friendly rivalry with each other.  Each approach seems to be dealing with project scaling differently.

My first exposure to scaling agile was called, “scaling with scrum.”  The approach was very organic.  As an organization grew, the backlog of work would splinter into smaller backlogs.  These backlogs would then be delegated to teams and completed. In the end, these smaller backlogs would bubble up into a “master backlog,” so that leadership could track what was happening.  I liked it, but it did require plenty of administrative work.  It also assumed that everyone was in perfect communication with everyone else in the organization.

My next exposure to scaling came from the world of SAFe.  This framework has caught on with more prominent organizations because it has a command and control structure which is very familiar with executives.  Scrum Teams bubble up into release trains, and those trains have particular departure dates.  Networking, Software, and Hardware all obey scrum or a Kanban approach to work.  Leadership over three or four sprints then witness a “product increment” and inform what direction to take next.

I like SAFe.  It feels like a good marriage of agile and corporate structure.  I see three principle drawbacks.  First, executives can maintain a top-down approach to innovation and control of the software process.  Next, SAFe depends on quality Product Ownership, and this is the weakest area of the agile movement.  Finally, working in a SAFe development environment feels like being a cog in a giant wheel.  If we can figure out how to mitigate these issues, then SAFe might be the future of agile.

As an agile coach and scrum master, I have borrowed liberally from the scaling frameworks.  One of the tenants of the Agile Manifesto is, “…responding to change over following a plan.” So I found it necessary to incorporate elements of SAFe which work with those which can wait.  I use scaling scrum with scrum all the time in my agile practice.  I also rely on the suggestions and directions of my peers and management to get software shipped out promptly.

In my opinion, we are still in the awkward years of the Agile Reformation.  We are very good at shipping software from small teams, but when we try to scale to large multi-national corporations, we still have plenty of work to do.  Software is eating the world, and if we are not careful, it will consume agile and scrum.

Until next time.

Experience Matters in a Scrum Coach

Leadership experience is not pretty but necessary

Plenty of issues crop up in the day to day life of a scrum master.  Impediments need to be resolved and each day you are a living example of how Scrum is supposed to work.  As a fellow coach, Ryan Ripley remarked on how some individuals with little experience with agile are marketing themselves as coaches.  Ryan feels pretty strongly about the subject, and so do I.

There are two lines of thought about leadership.  The first school is called the “great man theory.”  This school firmly believes that great leaders are not made but are born.  This notion has been used for generations to support monarchs and other forms of tyranny.  For each leader born into greatness, there are numerous counterexamples of individuals who fall woefully short.  There is also an elitism and snobbishness associated with this school of leadership which says that only specific groups can aspire to leadership.  I also find this type of thinking has plenty of sexist and racist baggage associated with it.

The second school of thought is the notion that leadership can be taught just like any other skill.  I am a firm supporter of this idea.  When I was a teenager, I benefited from leadership training from Boy Scouts of America and Marine Corps Junior Reserve Officer Training Corps.  I had the Boy Scout Law ingrained into my personality at an early age.  The outdoor activities forced me to learn to help younger scouts cope with being alone and away from home for the first time.  Being caught in a rainstorm surrounded by wet and tired twelve-year-olds is a good measure of your leadership skills.

Marine Corps JROTC taught me self-discipline, my left form my right and that leadership is more about credibility than shouting at people.  I met some remarkable people.  David Ogle was a survivor of combat around the Chosin reservoir and a USMC boxing champion.  He served in Vietnam and became a Sergeant Major.  Richard Weidner was a company commander in Vietnam and taught me about the less than glamorous things leaders have to do.

Together, Boy Scouts and Marine JROTC gave me a good foundation from which to build.  I took that knowledge with me into the sales profession, the casino business, radio, and finally into technology.  I am entering the fifth year of being a scrum master.  The experience of shipping software at the end of each sprint changes a person and their style of leadership.  Working with offshore teams changes how you relate to others.  Those experiences make you a better scrum master and coach.

We can teach leadership, in my opinion.  I also feel experience acts as a multiplier of leadership skill.  A good leader does not ask someone to do something which they would not do themselves.  That means if you ask a developer to write a unit test you better be willing to write a few of your own.  An agile coach who has not led a retrospective or shipped code is not a coach because they lack the practical skills to make agile successful.  They are faux coaches, and you should steer clear of them.  An agile transformation is like performing a heart transplant on a person running a marathon; you would not trust that job to a first-year medical student.  Anyone can call themselves a coach, it takes time and experience to be a valuable coach

Until next time.

Process is a lame excuse

Responding to change is like jazz, blues, and rock

One of the central tenants of the agile manifesto is responding to change over following a plan.  For someone with a background in science or engineering it seems commonsense.  Sadly, many people in leadership roles see responding to change as a threat.  This week I want to talk about “process” and why it get in the way of agility.

I have plenty of late nights and early mornings on the phone with off-shore consultants.  These meeting are typical stand-up meetings familiar with co-located teams.  It is also an opportunity to share technical knowledge.  According to the scrum guide, stand up meeting should be fifteen minutes long.  The scrum guide does not take into account a team thirteen time zones away and working with complex legacy system.  So our meeting lasts about thirty minutes and we have follow up calls between individual members.  We have no formal process but the scrum guide is not helpful so we responded to change over following a plan and had a longer meeting.

Many business leader like to say they have processes in place to minimize risk.  It has been my experience that many of those processes are in place to maximize control because those business leaders do not trust their people to do the job correctly.  This makes me sad.  Instead of working with customers and solving problems, many people spend their days wrestling with the bureaucracy and process.  Confronted with this environment people loose initiative and motivation.  Eventually, nothing gets done except the stale process.

This may have worked fifty years ago but product cycles are measured in weeks instead of years today.  People need to be motivated and engaged if the wish to compete in this new business environment.  Process makes it hard for people to be motivated and engaged because it discourages original thinking and ownership of decisions.

That does not deter business leaders from coming up with more process.  To them, a business is like a symphony orchestra with every not scripted and every performer knowing his or her place.  If someone deviates from the music sheet or the conductors instructions then they are expelled.  I strongly disagree with this metaphor, I see a business like a jazz or blues combo.  The players have strong technical skills but com improvise based on the situation and can adapt to changing situations with the audience.  To a command and control business leader, this is unacceptable and a recipe for chaos.  To the agilest, it is responding to change over following a plan.

One of my favorite stories about Jazz history is about Benny Goodman.  A critic said his music was immature and untrained.  Goodman responded by recording Mozart’s Clarinet Quintet in A major to critical and popular acclaim.  In a more modern context Wynton Marsalis plays trumpet in both jazz in classical situations.  Finally, Trombone Shorty easily transitions between Jazz and Rock music.  In short, it is common for jazz musicians to cross over into other styles of music while it is uncommon for classical performers to do so.  I blame the “process” of training and conditioning of classical musicians who struggle in ambiguous creative environments.

This is the big challenge of business.  Do we want our employees to be like classical musicians of like jazz musicians?  In my opinion, I am going to trust my business to the jazz nerds.  The will be able to respond to change when necessary.  This is why I rebel against process.  I see process as a necessary evil.  I also see it fungible and able to change.  This drives my superiors crazy because sometimes the process is the only thing which keeps them in control.  Squeaky wheels often call attention to a bad axle and managers hate that.

So I say to you, treat process with contempt and skepticism because it is an excuse for behavior at a company rather than a reason.  This makes it impossible to respond to change.  W.E. Deming said, “Survival is not mandatory,” if you follow process chances are you are more likely to become extinct.

Until next time.

Making a Difference

How does a scrum master describe his job at the
office party?

The other night I was having dinner with someone who worked as a nurse.  I understood what they did for a living and when they discussed their work it was easy to understand their frustrations and successes.  Then I told them I was a scrum master and they gave me a blank stare. It seems the world of technology has not filtered out to the fly-over country and so I spend a lot of time explaining to people what I do for a living.  This week I thought I would help others have that awkward conversation about what you do for a living.

At first, I struggled with metaphors to describe what a scrum master does.  In a way, we are coaching helping software developers and business people do their work faster, better, cheaper, and with less hassle.  It did not seem adequate.  Then I thought about Stephen Ambrose and his book, Band of Brothers.  A scrum master is like a platoon leader for a group of para-troopers.  They lead, look after the well-being of their people, and are on the front lines of the software development action.  It seemed a stretch because I do not jump out of planes or get shot at by enemy troops.  May-be a scrum master is like an orchestra conductor getting developers and the business to play together.  Again not very good because classical music does not have a culture of improvisation that developers use to get the job done every day.

May-be I should skip the metaphors.  Each day, I work with developers from Chennai, India.  Then I go into the office and try to work with the on shore developers.  Next, I help my product owners learn to write business stories.  I spend a few minutes being demeaned by my project manager and try to stay positive for my software developers and my business leaders.  I manage up setting expectations and receiving one-word e-mail replies from vice presidents who don’t have time for me unless something is wrong.  I am sweating deadlines, answering awkward questions, and pushing the people I am responsible for to complete deadlines.

I have to be a cheerleader staying positive in some of the most discouraging situations.  I have to be an actor because I have to receive abuse and condescension from business people and say that I like it.  I am a business consultant showing people how to do things a better way and I am a therapist as I help my developers get through personal problems and business frustrations.  It is also a calling like being a member of the clergy because we are pushing people to see a better way.

The best answer I can give is that a scrum master makes a difference.  Many of the software products you use and the apps on your phone are built by software developers.  The scrum master makes sure that construction gets done.  The scrum master keeps the wheels of the global economy spinning as they take numerous conference calls and sitting through endless meetings.  We are not middle managers; we are on the front lines making things happen.

So the next time someone at a holiday party makes a remark about what they make, smile and given them a steely stare and say you make a difference.  It is the only way I can describe what a scrum master does.

Until next time.

How my agile is changing.

Those of us in the agile community spend a lot of time talking about building software and helping our business partners.  What I have discovered over the last six months is that for a large organization like mine agility is a relative concept.  What I am discovering is that the business is struggling to keep pace with the developers.  This week I want to provide a few helpful tips to explain how you can help your pals in the business keep up.

Have a release plan – 

Software projects in my organization have a budget along with a beginning, middle and end according to the executive leadership.  To the suits at corporate, they don’t know or care about sprints, iterations, and burn downs.  So we have been forced to come up with a bridge document between the backlog and what the leadership expects.  This is the release plan.  Since my leadership does not understand the terms epic, theme and story; we substituted the words milestone, feature, and story.  This made it easier for the executives to follow along.  In our backlog we organized everything by milestones then placed features under them and finally had stories under those.  What happened was a revelation.  The business owner knew what was expected to be completed and then wrote stories to accommodate that structure.  Sprints were now planned around delivering features and we were doing better at delivering what the business wanted instead of what the business owner wanted.

Metrics –

Professional athletics is concentrated on metrics.  How fast you can run.  How high you can jump.  How many interceptions you throw during a football game.  The game of metrics has been transformed by the practice of sabermetrics and “Money Ball.”  Development which is done primarily by engineers has been very poor at measuring performance.  This is why I have started to measure the team velocity in story points.  I am also comparing the amount of work scheduled versus the capacity of the team.  This provides the team with positive reinforcement along with upper management a way to gauge how we are doing.  I will also be doing more advanced things like comparing bugs with velocity and understanding if we have good code quality compared to team morale.
 

Developer and Scrum Master training –

I find it interesting that we are working on software which runs the business but the developers and scrum master do not know a lick about the business.  That is changing.  I am spending about 90 minutes a week learning the business with people on the front line.  This training will become a training program for all the developers on the team.  Each of us working on the project should be competent enough to work as an entry level employee using the software.  This is a new experience for me and my developers.  I don’t know why we did not think of it sooner.

Tender loving care for the business owners – 

My organization has had a spotty record with business owners.  They have taken a training course in how to be product owner and then they have been left to fend for themselves with little direction from their business units or help from the scrum teams.  I have made a point of each business owner I work with giving them a copy of Roman Pichler’s fine book “Agile Product Management with Scrum.”  I also spend time with them helping them groom stories so that the developers know what they are doing and can deliver that in one sprint.  I help them tie stories into the release plan.  The product owner has one of the hardest jobs in an agile organization.  Your scrum team will not succeed if the product owner doesn’t.

The most important part of the agile manifesto is to adapt to change over following a plan.  Well we are changing and this is how we are doing it.

Until next time.

The Bring Your Own Device revolution

The revolution is here. 

Revolution is messy.  Protesters march in the street and buildings are burned to the ground.  In the end, the old order could become stronger than before or the rebels triumph and have to figure out how to take charge.  Today on the blog, I want to discuss a revolution taking place in the business world;  the bring your own device revolution or BYOD.

Bring your own device began in earnest with the release of the first iPhone. Prior to this date, when you joined a large company and needed a cell phone the company issue it to you.  This was great for the company because the company could control the number of minutes, configure the devices e-mail, and place primitive application on it for critical business functions.  Control and economies of scale was the name of the game.  The release of the iPhone turned that model on its head.  Hot shot executives and sale people snapped up these new devices from Apple and brought them into work.  These individuals demanded they work with the current IT infrastructure.  The BYOD movement was born.

Since the iPhone did not support Flash, CEO’s demanded web sites which worked on their new-fangled phones.  This was the primary reason why the use of flash declined on the web.  The advent of tablet computers and personal laptops make this trend accelerate.  Now companies had to maintain its own computers and support numerous tablets and smart phones which were used by employees.

At E₃ systems we have known about the BYOD revolution for some time.  We constructed both our Sully inventory system and our Tony fleet management system with mobile devices and tablets in mind.  Our software is hosted on the cloud so it does not need to be installed on your devices.  If you have a web browser on your phone, tablet or PC then you can use our product.  This is why we say that our software is easy, economical and everywhere because if you can connect with the web then you can use our systems.

People may not be protesting in the streets and building may not be on fire but we are in the middle of a revolution.  E₃ systems know how to navigate these troubling times and look forward to helping you today.  Contact us now.

Until next time.

Introducing Tony - Our Latest Product

Your Fleet Maintenance never looked
so good. 

More than cash, the common currency of an entrepreneur is trust.  If customers and client can not trust you your business is doomed to failure.  Today we at E₃ systems are proud to announce that we are releasing our Tony fleet management system.  This week’s blog post features our new product and how we kept our promise to our customers.

Tony was conceived in February of 2013; as we looked at the marketplace and realized there was no good tool for tracking maintenance on a fleet of vehicles.  Trucking companies, school bus services, rental car companies and farmers did not have a good tool to keep track of when and what kind of maintenance they did on their vehicles.  We decided to write one.

The system like all E₃ products works on a smart phone, tablet or regular PC. It is based on the cloud so there is not software to install or upgrade.  Finally, we made our system easy to use and economical for consumers.

With Tony you can QR code your vehicles so that anyone with a smart phone can view the maintenance history on a vehicle.  Paperwork is a thing of the past as a few key strokes can pull up a vehicle and the history of maintenance for it.  In addition, when you are confronted with law-enforcement or insurance requests for vehicle maintenance you can provide them with that information from any device with a web connection.

We went through an exhausting testing program to make sure we had a great product to offer you.  Now we are pleased to say it is here.  Contact us today and we will tell you more.  This is just one more way we are trying to earn your trust.

Until Next time.

The Summer of E3

Looking forward to the Summer of E3.

I hope that everyone had a good Memorial Day weekend.  I also hope you took some time out on Monday to remember the people who sacrificed everything for this unofficial kick off to summer.  For E₃ systems, it is a chance for us to snag our first customers and start the process of growing our business.

I am going to take some time to visit some clients face to face.  We will also be prospecting our rolodex heavily.  Finally, we are going to participate in J.P. Morgan Chase's small business challenge.  We are closing in on our one year anniversary and I am pretty proud of what we have done so far.  First, we have constructed a cloud based inventory management system which is easy to use.  We have established a presence on social media like Facebook, Twitter and Google+.  Finally, we have started to embed into the community being known as the scrappy technology start up in Joliet. 

This is a good time to be an entrepreneur.  According to Logistics Management magazine, just under one third of supply chain companies are looking into using software as a service or cloud based computing.  In addition, these companies are looking to spend less than $100,000 to try and meet this need.  We are perfectly positioned to serve this market. 

Looking back to my summer vacations when I was in college, what strikes me about those periods was how I used the time to emotionally reset and focus on future goals.  This summer I am going to repeat that pattern as I emotionally recharge from the launch of Sully 2.0 and make a point of seeing some customers.  The change will do me some good and help drive some sales.  2012 is going to be the summer of E₃.  I look forward to sharing it with you.

Until next time.

Sully 2.0

To look at the features of Sully 2.0 scan the tag. 
You will be glad you did.

Today is the launch of Sully 2.0. It is the product of almost eighteen months of work and countless refinements suggested by potential clients. With its release we shall be pushing for sales and make our mark on the small business software market. In this blog, I want to talk about the specific features that set Sully 2.0 apart from traditional software offerings for small business.

The most important feature of Sully 2.0 is that we are leveraging the power of cloud computing like no other company. This means you can do more for less money. When comparing software systems on the market we discovered that many of our competitors required you to install new servers and software to use their systems. We do not. All you need is a connection to the internet and a standard web browser. We have tested our application with Internet Explorer 8, Firefox and Google Chrome. If you have any of these web browsers it will work. By using our system, you have already saved thousands of dollars in unnecessary hardware.

Next we have made bar coding easy for products by leveraging Microsoft Tag technology for you to place two dimensional bar codes on any product or piece of paperwork. You don't need any special bar code scanners or technology. All you need is a smart phone with the Microsoft Tag application which is freely available. Tag works with Android, IPhone and Windows 7 mobile phones so now anyone in your office with the correct permissions can barcode scan items and follow inventory or pieces of paperwork. This saves you hundreds of dollars because now you do not need to purchase bar coding equipment.

The application makes it possible to track bills of lading, invoices, packing slips and purchase orders with the click of a mouse or a swipe on your mobile phone. This means you don't have to be in the office in order to do business. Now you can be meeting with clients face to face and tell them exactly how much you have on hand to sell. You can follow up on a shipment from your laptop and if there is a billing dispute you can check to see who is responsible for the freight. It gives you the freedom to run your business without losing track of your paperwork.

Finally, this system is easy to use and expand. You can start with a few products and grow to handle hundreds of thousands of items. For less than the price of cable television, you can have a system which makes it possible for you to manage your shipping and inventory just like a Fortune 500 company. We are pretty proud of this accomplishment and this that it is the right tool at the right time to help you grow your business and satisfy your customers.

Normally, I don't want to hard sell my products but I think that you will like what we have to offer and should tell your friends and colleagues. Scan the tag on the page, share this blog with friends and feel free to tweet about our services. We are trying to make logistics software easy to use and economical and we hope you can help us on this journey.

Until next time.

Watch Me Pull a Rabit Out of My Hat

Pulling a Rabit Out of a Hat is Hard!

One of the biggest constants in software development is failure.  Projects fail to get completed on time.  Software fails to work as expected and software developers fail to keep their jobs.  It is a vicious cycle and it takes an emotional toll on the people who spend their time working on it.

People want to be successful and competent.  Software humbles the smartest and best of us.  Add to the mix unrealistic time pressures, unhealthy lifestyles, and marketing professionals forcing me to keep their promises and you have a blueprint for mental illness.

Shortly after my wife moved out of the house, I sat in a planning meeting and I had a revelation.  A business analyst was talking about improving the click ratio for a page and it just dawned on me.  I was living in a bizarre world where people were making decisions about my work and life and they had no understanding of web development or the challenges it entailed.  To them, it was just like magic.  All I had to do was pull out a rabbit from my hat each day and hope I could correctly guess the exact color, size, and fur quality these people expected. 

I was not a professional with an opinion to be respected.  I felt like a birthday clown making balloon animals for ungrateful children.  Something had to give and I slowly began to start planning for the launch of E₃ systems. 

In the almost two years since, I have been writing code after hours and on weekends.  I put together a business plan and I have rounded up a board of directors to help me.  I even have a sales person.  All that is left are customers, because contrary to popular believe, just because you build something they may not buy it. 

I am not deterred because this has given me time to refine my production and this month we will be doing a 2.0 release of our Sully® Warehouse Management System.  I am pretty proud of it.  We now make it possible to manage inventory, bills of madding, addresses, invoices, packing slips, and not purchase orders.  I even have a movie version of the application which works with Microsoft Tag so that a piece of paper automatically communicates with a smart phone or tablet. 

What makes this so fantastic is that is less expensive than most software packages on the market.  There is not software to install and it works on most modern browsers and smart phones.  It is cloud based computing without the hype. 

I will have more news about the release of Sully® 2.0 as we complete testing.  We also have YouTube videos going up and we are putting together a training manual.  We are also going to start a full court press for customers. 

Two years ago, I looked and felt like a clown.  Now, I am on the cusp of being a full-fledged entrepreneur.  It is worth the wait. 

Until next time. 

Never Good Enough

Being creative is fun but mighty frustrating
in the world of web development

The other night I was meeting with a potential client.  We discussed his needs and how our Sully® application could help him.  It was a very positive experience.  The interesting thing was listening to the customer talk about the software. 

“That is cool,” he said, “but it would be even cooler if it did this!” 

That line has spawned millions of dollars in consulting fees and countless hours of frustration for developers.  It is the source of all feature creep in any project plan.  I felt a ball of bile welling up in my throat after hearing the client utter that phrase.  I took a deep breath and the madness subsided but it made me wonder if anything a software developer does is ever good enough.

I do not think it is a secret that developers are a quirky lot.  We are highly intelligent, have an in demand skill and often behave like professional baseball players jumping from team to team for better money and perks.  I also speak from experience that we often see ourselves like artists.  This explains why as a group we can get defensive about what we do.  Spending hours of effort to get something to work just right is emotionally exhausting.  When that effort is greeted with a shrug and the contempt of someone else it can drive a person crazy.

The feedback we often get from a business user is often inane and unhelpful.  You only have to watch a scene from the movie Amadeus to see a classic example of this criticism at work when the King of Austria tells Motzart his opera “…has too many notes in it.”

It has taken me over twenty years to learn how to deal with all kinds of customer feedback.  These lessons have been painful experiences found during bouts of unemployment and stress.  It amazes me that I did not discover them sooner. 

Business user approach software the same way many of us listen to popular music.  We don’t understand the technical details of how to play music but we know what we like.  So it doesn’t matter to most people that a song is being played in the 2/4 time or that it is in the key of G.  We just know that Credence Clearwater Revival's “Bad Moon of the Rise” is catchy.  So when we dislike a song we ofter have an emotional reaction to it rather than a rational one.  We can criticize it saying it lacks harmony and the minor key is off putting; instead we just say we don’t like it.  Often we sound like dancers on the old American Bandstand television program claiming “That song has a good beat and you can dance to it.”

Replace popular music with software and it is the same experience.  People interact with software much like they do with music.  I suppose that is why there are so many Linux and Apple fan boys.  This is why I do not get aggravated as I used to when someone suggests improvements to my software.  They know what they like and they are just having trouble describing it to me. 

I start asking questions of the customer and try to find out what they are looking for.  Eventually you will get a meaningful answer to your questions and know what to change.  I also know how serious about these improvements they are when I ask if they are willing to pay extra money for that service.  If the answer is "yes" then I know they are pretty serious. 

I have just come to accept that most software work is not good enough and that the users will always ask for something faster, better and cooler.  That is a good thing because this quest means that we are making better products which will create a virtuous cycle of innovation. 

I just wonder why it took me twenty years to figure this bit of wisdom out.

Until next time.

Why I Use TFS 2010

Team Foundation Server 2010 is not a muscle car.

Developers are a temperamental and combative in nature.  Many business people justifiably treat us like the troll under the bridge due to our gruff and matter-of-fact way of addressing controversy.  Some of us even look and smell as bad as these mythical creatures.  Nothing inspires more troll like behavior than developers debating which technology or tools are superior.  Another chapter in this ongoing discussion came from Derek Hammer and his blog “TFS is destroying your Development Capacity.”  This article is well footnoted, inflammatory, and filled with plenty of reasons not to use Microsoft’s Team Foundation Server 2010 or TFS for short.  I want to take time to answer some of his criticisms and explain why I am sticking with TFS for my business. 

Hammer’s criticisms are fairly clear:

1)      TFS version control is frustrating to use.
2)      Bug Tracking is hard to use.
3)      TFS is not flexibile enough for Agile project management.
4)      The build system is clunky.
5)      Finally, the vertical integration of the product makes it impossible to use best practice tools.

Let us start from the beginning, if you grew up in the business with Visual Source Safe and Visual Source Safe 2005, you will understand that TFS is a quantum leap forward.  Code can be exclusively checked out to one developer or several developers can work on the same code and merge it together.  Also the ability to branch and merge code is clean and easy to understand.  This makes it possible to have code in development, staging and production environments existing in source control.  This is a huge help if a problem crops up in production and it cannot be reproduced in the other environments.  The label and history functions make things easy to track and using project settings forces developers to comment check-ins and associate check-ins with work items. 

Hammer does have some legitimate gripes.  TFS forces you to be connected to the server via your “workspace.”  This is a bit of a pain for people who think source controls consists of copying and pasting folders.  Fortunately, this criticism will soon be moot because the next version of TFS will allow you to work locally and then connect to the server to synch changes.  He also talks about a simple four window three-way merge.  Personally, I have not seen this and I did not even know it was a standard.  I would like to see an example of this.  Please leave a link in the comments. 

Next, Hammer dislikes the bug tracking system.  This was what sold me on TFS.  Work items, bugs and tasks can be entered via Visual Studio or the web site which is built into the system.  The web interface in no more difficult than SharePoint and customer service reps can easily be trained on how to fill out the information.  Finally, TFS has its own API so if you are not happy with the interface you can write your own web form or MVC application to place bugs into the system. 

Moving on to Hammer’s third criticism, TFS is not suited to Agile management.  My biggest challenge as a developer and consultant has always been having the client adopt any kind of Project Management Operations.    This is particularly true in the organization that thinks project management consists of leaning over a cubical wall and asking a developer to build a website.  Thus, TFS is a fantastic introduction to agile and its principles.  I still use a white board for the project team however; TFS helps creating excel reports for management a breeze.  Also, I create custom reports all the time to view specialized data.  When I was at a client, I act as scrum master entering data into the system and leading the project.  I also spend a lot of time training others on how to use TFS to get the most out of the system.  For a mature Agile teams, TFS may seem like an impediment but for companies just getting started, it is the perfect set of training wheels.

Next, Hammer talks about how the build engine is clunky.  Without any reservations, I can agree with his criticism.  In my nearly two years working with TFS, the build system has frustrated me the most.  Often, I simply rely on Microsoft Visual Studio’s publish tool, web.config transformations and FileZila to get work done.  Fortunately, I see this changing.  The Chicago ALM group had a great meeting on Sept 14^th 2011 illustrating how to customize the build process and I look forward to more people coming forward and sharing their knowledge of the subject.  Until then, I am sticking with FileZila. 

Finally, Hammer criticizes the vertical integration of the product and how it is endemic of “The Microsoft Way.”  It has been my sad experience that most people who make decisions about technology are not technologists themselves.  Thus, they are not thinking about best practices or better ways of doing things.  To this kind of individual vertical integration is a perk and not a defect.  With TFS, they see and all in one package that is easy to install and does what is required of it.  This leaves it up to the technologists to us the tool they have been given as best they can.  If that means we write web apps for the customer service people to put bugs into the TFS system and we run reports each week and send them out as excel, so be it.

Let us compare software to automobiles for a moment, Hammer sees TFS as a clunky minivan which gets people from point “A” to point “B” with little speed or flash.  What he wants is a sport car where he can open the hood and swap out engine parts for better performance.  Talk to any Mom and they will tell you when push comes to shove they will settle for the minivan.  This is why most businesses are moving to TFS as well.   It may not be sexy and flashy but it gets the job done in a way technical and non-technical people understand; this why I am sticking with TFS.  I understand the tool.  I know that I can train other developers how to us it.  Finally, it makes sense to business people who usually pay the bills. 

As someone who used to be a troll under a bridge, I understand Hammer’s perspective.  Now as I begin my own company and transition to working with C-Level executives, I see that there is more to a technology decision that just the technology itself.

We have lift off!

We are now live and on the web. 

Please visit our site at: http://www.goeeethree.com/

Look forward to seeing you.