Sprint Planning Isn't Hard.

Sprint Planning can be easy. 

An agile development team is like a stool with three legs: each team has a scrum master, a product owner, and the development team.  The team practices the values of the agile manifesto and the principles of agile development.  The scrum guide outlines several rituals where the team plans and prepares for work on the next sprint.  Efficiently running sprint planning can set up the team for success, and this week I want to provide some tips on making your sprint planning sessions better. 

As a product owner, it helps to follow Roman Pichler D.E.E.P. framework for a product backlog.  Stories should be detailed, estimates, emergent, and prioritized.  Sprint planning depends on correct prioritization to be successful.  The product owner arranges the backlog from highest priority to lowest.  All the bugs, stories, and spikes in the sprint should have a preference.  The team takes those stories and adds them to an upcoming sprint.  It is an ideal time for the development team to ask the product owner additional questions.  

On a high-performing team, all of the backlog stories are estimated through a process I call backlog coaching and refinement.  At this point, the team adds as many stories as necessary to keep the team busy for the sprint's timebox.  If the team uses story points, you take the team's velocity and place that number of story points into the sprint.  If you use a no-estimates approach, then add the total number of stories completed into the sprint.  Either method will work depending on the team.  

Finally, sprint planning is the meeting facilitated by the product owner.  Since the product owner is responsible for the backlog's health and what the team does next, they must explain user stories to the team and justify the work's priorities.  It is also up to the product owner to respect the social compact of agile. They must accept developers' timelines in exchange for the developers receiving the priorities of the product owner.  

The sprint planning session should be a collaborative meeting facilitated by the product owner to plan the work which needs to get done.  Once finished, the team should have all the necessary information to have a successful sprint.  It takes practice and obeying the D.E.E.P. framework for the backlog, but the team's efficiency will improve, which makes the struggle worth it.  

Until next time.   

Scrum does not have too many meetings

Each reform in society is confronted with a backlash.  The Protestant Reformation spawned the Inquisition.  It is natural that those threatened by it would oppose progress.  It is happening in businesses across the nation with the Agile reformation.  A common objection many have toward agile or scrum is there are too many meetings.  This week I want to discuss agile and meetings.

According to the scrum guide there are four events in scrum, they are:

• Sprint planning
• Daily Scrum or Stand-Up
• Sprint review 
• Sprint retrospective.

In the span of a work week, these meetings should be brief and informative.  A stand-up meeting should take approximately fifteen to thirty minutes.  If it takes longer, you should review how you are facilitating this meeting.  A sprint review is a demonstration to the business users and should take no longer than an hour.  Retrospectives allow a team to inspect and adapt their process.  Typically, this meeting is about sixty to ninety minutes in length.  Finally, there is sprint planning where the development team estimates stories and plans the next race.  Sprint planning can take as little as an hour and as much as six.

Based on this rough estimate we can determine how many hours the agile team is spending in meetings.  Based on a three-week sprint where is how it break down.

• Typical work week 40 x 3 = 120 hrs.
• Standup meeting – 0:15 x 15 = 3:45 hrs.
• Sprint Planning – 6 x 1 = 6 hrs.
• Sprint Review – 1 x 1 = 1 hrs.
• Retrospective – 1 x 1:30 = 1:30 hrs.
• Total Time budgeted in meetings = 12:15 hours of a 120 hrs. sprint.

Thus, a developer at worse case scenario spends just over ten percent of their time in meetings.  The remainder of the time is devoted to writing software and creating value for customers.  It is significantly less than in the world of waterfall project management with its numerous meetings to cover everything from architecture to problem-solving.

The scrum master and product owner spend their time in meetings, but it is to protect the team from being distracted from delivering value.  It is why I attend meetings about I.T. governance or architecture so that my team does not have to.  It is why the product owner is answering customer inquiries and meeting management.  We attend the meetings so the development team can concentrate on what is important which is shipping code.

It is why I find the argument that agile has too many meetings disingenuous.  People who are opposed to agile are not opposed to the meetings they are opposed to the routine nature of the meetings and the expectation to ship working code at the end of each sprint.  Transparency of this nature quickly exposes the unwilling, incompetent, or invisible people in an organization who do not deliver value.  When we discover these individuals, it creates a backlash in the organization.

So, scrum and agile does not spend too much time in meetings; it concentrated on what is essential.  An agile team’s first and foremost duty is to deliver value to the business; anything else is waste.  I am looking forward to hearing from you and knowing what you have to say.

Until next time.

Planning is Everything

This scrum master
wants to be more like Ike.

It takes plenty of emotional energy to be a scrum master or agile coach.  Developers need guidance, product owners need constant coaching, and upper management is always asking for status updates.  It is psychologically exhausting.  Along with day-to-day chores, you are planning and setting strategy.  This week I want to discuss how planning and responding to change are not mutually exclusive.

According to the Agile Manifesto, responding to change is more important than following a plan.  Situations in technology are changing at a rapid clip and an idea that seemed plausible an hour ago can be hopelessly out of date.  Agility depends so much on responding to change.  The unintended consequence of this is business leaders abandoning planning altogether because “We are doing agile we don’t need plans.” Let me try to add a little sanity to this discussion.

The manifesto states, “…while there is value in the items on the right, we value items on the left more.”  Planning has some value and should not be abandoned because we are responding to change.  It seems like a contradiction.

Planning is an integral part of agile.  A scrum team does sprint planning before the start of a sprint to decide what they are going to do.  The product owner does release planning to prioritize stories in the backlog.  A plan makes it possible for an agile team to understand the nature of the problems they are trying to solve.  It also allows them to learn how to respond to change when the inevitable happens.  It explains why Dwight David Eisenhower said, “Plans are worthless, but planning is everything.”  When a team plans they are going over possible scenarios which might happen during a sprint.  The team is also doing much of the analysis necessary to start writing unit tests and code.

To use a metaphor from music, Jazz and Blues musicians still rehearse even though much of their music is improvisational.  The players outline key progressions and cords they are going to play.  It is the plan they use for their performance.  Once the concert begins, situations may dictate a deviance from the scheme.  Thanks to the outlines figured out during the rehearsal, these musicians can respond to change.  The same thing happens to a development team during a sprint.

So responding to change is important but you cannot respond to change unless you have spent some time planning to understand what changes might happen.

Until next time.

More than the Man in the Taupe Blazer

I am a guy from a state school with a
taupe blazer.  I am going to help you
get your software written on time.

I have had a lot on my mind the two weeks.  My day job is getting more challenging and my home business is puttering along as it always has.  The most interesting thing about working in technology is the pace of change.  If you don’t like something it is bound to change in the span of a week.  This week I wanted to devote more attention to the fine article in Bloomberg Business Week, entitled “What is code?”  For the beginner in technology it is a fine read, but it does get a few things wrong and in particular they get wrong the role of the “scrum master.”

In the first chapter of the rather long article they describe a “scrum master” as “The Man in the Taupe Blazer.”  According to the article:

“This man makes a third less than you, and his education ended with a B.S. from a large perfectly fine state university.  But he has 500+ connections on Linked In.  That plus sign after the “500” bothers you.  How many more than 500 people does he know? Five? Five thousand?”

In short, a Scrum master is an eccentric person who understands software development along with project management and if a project goes south they will be able to get on with their lives while the executive who hires them will be forced into early retirement.  At first glance this is not an unfair impression.

What the article missed is that a scrum master is just as invested as the executive who hires him.  One of first things a scrum master learns is the difference between involvement and commitment.  To be committed, is to put your career at risk if you don’t succeed.  To be involved, is to be a participant in a project with no repercussions should it fail.  This gets to the classic metaphor about the breakfast shop and pigs and chickens.  In my darker moments, I joke about being a pig because I live on a steady diet of garbage, live in the excrement of other pigs, am treated with contempt by the other farm animals, and when necessary butchered for someone else’s breakfast.

I am not far from the truth.  I don’t know how many times I have had a member of my business organization look at me like I am some kind of insect because I am not as; cool, professional, good looking, or credentialed as they are.  I also spend many moments of my day slopping through the mud of my company bureaucracy and infrastructure to get things done.  I have had people lie to me and get insulted when I point out they are lying to me.  I also remember the week before Christmas 2008 when I was slaughtered because I made a mistake after 14 hours of non-stop coding.

So to be clear my executive friends, many of the scrum masters you face have seen failure first hand and they do not wish to experience it again.  They also know that their success is dependent on the same things that make you a success which is getting the project finished on time and on budget.  We are not some empty shell in taupe blazers.  We are just as invested as you are.

Where we excel is that we understand software and the people who write it.  It is not a pretty job but for every skyscraper built it requires hundreds of people who understand, engineering, construction, and motivating construction workers to get the job done.  The tower may have “Trump” on its marque but it took an anonymous engineer with decades of experience to make it rise.

Unfortunately, software development is not construction in the conventional sense.  While buildings are constructed with steel, glass, and concrete, software is built using languages and systems that often do not play nice together.  We also have differing levels of training and experience which is not taught in schools but rather learned on the job so asking a developer to do something that seems routine can be a huge suck of time and money.  Also software developers, the good ones at least, see themselves as artists.  Which means they cannot be led around like construction workers.  They have to be treated like the smart professionals they are.  Instead, they are treated like expensive pigs ready to be sacrificed when a project goes bad.

Yes, I have a taupe blazer.  Instead of a Bachelor of Science, I have earned a Master’s in Management and I have earned numerous credentials in my field to prove to executives that I know what I am doing.  I also have over 17 years writing software and learning how to adopt to the new technologies.  I am your ally.  I am just as invested in the success of the project as you are.  Finally, if you give me what I need to succeed, I will.  So have a little respect for the scrum master’s in your life executives, we are the steady hands which make software work for your business.

Until next time.

Software and Your Local School Bus Company

Would you like to know how well maintained
your child's school bus is?

We see them every do and we really do not give much thought to them.  On our way to work we pass them by and do not give them much thought.  Rarely do I even think about them when I see them pick up young people on their way to school.  I am talking about school buses and each day communities blindly trust companies we know little about to safely transport our children to and from school.  It is a pretty serious business filled with insurance risks and major expenses. This week I want to discuss how our software Tony can help school bus companies stay on top of maintenance and insurance expenses.

When I began writing Tony a year ago, I was thinking about truck fleets but after speaking with a few bankers and other people I decided that I should expand the focus of my software to include farm equipment and other types of motor fleets.  I even met someone who worked for a porta-potty company who though my software could help him.  It took a few detours and corrections but now you can track the maintenance of how your items are maintained by either hours of operation, mileage or simple date.  This makes it perfect for just about any business which has hard assets which need maintenance.

This brings me to school districts and school bus companies.  I am sure as a parent you would like to know how often the breaks are fixed on each bus.  Oil needs to be changed and tire pressure maintained.  Our Tony system makes tracking that information as easy as a click of a mouse or the swipe on a smart phone.  I am very excited about it and if you are managing a bus barn then you should be too because now with the scan of a QR code on a bus you can see up to the moment when work was done on the vehicle.  This will give additional piece of mind to the school board and parents who are curious about the buses their children ride on.

More importantly, we can see how our systems can help with insurance adjusters and companies.  For example, if you are involved in an accident you now have proof that you did actual maintenance on the vehicle and that mechanical failure can be ruled out as the cause of the accident.  In addition, these detailed records can be used as a means to negotiate with an insurance company to make sure that you get the most economically efficient rates you can from your insurance firm.  So using Tony is a great means to track maintenance and reduce insurance costs and liability risks.

At E₃ we are constructing these systems because we want to have easy and affordable means of helping small businesses stay on top of their fleets.  Contact us today to learn more about how we can help.  An account executive will give you a call and together you can discuss how we can improve your maintenance records.

We do not pay much attention to school buses unless something bad happens.  With the help of E₃ systems Tony we can help you save time, money and help postpone the bad things from happening.

Until next time.

To Big to Succeed

People have a right to get upset about
Healthcare.gov

Like many people in the technology business, I am following the news of the roll out of the Healthcare.gov website with a mixture of horror and disbelief.  It is clear to me that the current occupant of the White House deserves some criticism for this roll out; however, I also think a huge dose of criticism should be leveled at CGI International who is doing the principle development.  In this blog, I want to discuss why consulting companies like CGI International are too big to succeed.

In the book “The Geek Gap,” Bill Pfleging and Minda Zetlin say that technical leaders and business leaders view the world on very different terms; the business leader is interested in control and influence while the technical leader wants to build things which work.  It is clear to me that CGI is more interested in influence and control than building working software.

During congressional hearings with representatives from CGI about the Healthcare.gov roll out, no project managers were discussing the problems encountered.  More aggravatingly the congressmen did not know which questions to ask.  So you had people who negotiate contracts attempting to justify why they should get paid to people who did not understand what they were paying for.  It was depressing.

What makes this even more frustrating is that there are great examples of technology and government working together.  Each year Intuit makes millions of dollars helping people do taxes.  They are able to wade through the income tax regulations and each year release software which helps people do their taxes.  Even if the law changes, they are able to update the software over the internet.  If Intuit can do this each year why can’t CGI?  This answer is that CGI, from the outside looking in, is the antithesis of an agile organization.

They value process and tools over individuals and interactions.  They are more concerned with obeying the letter of a contract that providing collaboration.  Finally, they don’t have working software but they have plenty of documentation of why they should be paid.  Of course, this does not matter because, CGI is highly successful and so deeply embedded into the project that firing them for a poor job would be foolish.  In essence, they are too big to fail.

I had a hunch something was wrong when I reached out to my local congressional representative by e-mail and phone offering to pitch in and author some web services.  The congressional office had a staffer contact me and assure me that everything was under control.  When I asked if there was a way to volunteer for the project, I was instructed to follow the federal procurement process.   As a two person technology start up, I decided that it was not worth the hassle to get further involved.  I am sure that other start-ups felt the same and that is why firms like CGI make money.  They provide lousy service but they understand government procurement so they do not need to excel at fulfilling contracts only closing them and getting paid.

Healthcare.gov could have been a smashing success out of the gate, but thanks to a bad procurement process and a firm like CGI, it began with a thud and is slowly being made functional.  I hope that the November 30th release is a huge success.  I did not go into business to become CGI; I went into business to build things which work and solve problems.  I hope this is an object lesson to our elected leaders being able to win a contract does not mean that they can actually do the work.

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.

Crazy, Junky Technology

Technology should not be like working with trash.

As an entrepreneur, I spend a great deal of my time keeping up on the latest literature.  I also spend a great deal of time coding for both my day job and for the company I have founded.  This week I have received a reprieve of sorts.  I am getting ready for my company trade show.  My experiences are further reinforcing my belief that for many businesses we are way behind the times.

You would expect during a trade show vendors would use mobile applications to manage buying and selling.  You would also expect them to use their smart phones to conduct business with the help of applications like Square.  No, I am spending the next four days loading primitive Windows CE devices to attempt to handle transactions.  Each device has to be individually updated and they do not synch with the web but instead over Wi-Fi to a proprietary database; if it sounds like madness that is because it is.

This would be so easy if the system was connected to a secure cloud based application which worked on the vendors own smart phones.  No set up time.  No primitive devices to configure and finally, a technology that the vendors know how to use because they use their smart phones all day.  I think that smart phones and other mobile devices are the key to success in this marketplace and I see too many small businesses let this trend pass them by.  Even the not so small business which I consider my day job doesn't quite seem to understand.  It is frustrating.

This is why when I founded my company I made sure that I had applications which worked on both the web and on mobile devices.  You should look into us and find out more. 

It just seems crazy that I have to spend my time supporting outdated and obsolete technology.  It is just as crazy that you do too.

Until next time. 

A Trillion Dollar Trend

One Trillion of anything is huge.

I hope that everyone had a good holiday weekend.  During the time off, I stumbled upon an interesting article about Silicon Valley investment banker, Sanu Desai. For those who don't know who this individual is, he helped Amazon go public back in 1997.  As a venture capital banker he seems to know where all the bodies are buried in Silicon Valley and all the latest trends regarding money.  He said something this week which is directly relevant to our business this week.  The times are changing and we are about to the transfer of over one TRILLION dollars from companies involved in business to consumer products to companies involved in business to business products.  This is good news because it is part of a trend which we caught early.

E₃ systems has been pioneering a new cloud based systems which makes it possible to track your invoices, bills of lading, purchase orders and inventory online.  This is perfect for small and medium sized businesses.  You don't need to install software.  You don't need to purchase expensive servers and you don't have to worry about hassling with software upgrades.  We take care of this.  We are also perfectly focused on business users who don't have a lot of time for training their people to use new systems.  This is what makes Desai's commentary so heartening.  The technology business has spent the last twenty years making life easier for consumers.  Now it is time to make life easier for business owners. 

As technology has gotten to resemble magic more and more it is becoming hard for the small and medium sized business to provide the same kind of customer service which larger companies provide.  This is a big deal because you are now at a competitive disadvantage.  What I felt was needed was a technology service which makes it possible to provide the same tools the big firms have at a fraction of the cost.  What makes this even more important is that consumers are becoming more technologically savvy.  They will just take it for granted that they can track their products online and via mobile phones. 

This is where the one trillion dollars of wealth transfer comes from.  Larger firms like Oracle, Amazon and Microsoft will not be able to fill this important business niche. And so it will be up to smaller companies like mine to fill in the gap.  So E₃ systems is competing for over a trillion dollars of money up for grabs.  If we receive just a fraction of it then we will have accomplished our mission. 

If you want to learn more about how you can be part of this growing trend please give us a call we will be glad to help. 

I can't even fathom a trillion dollars of wealth.  There has never been a trillionare in the history of human kind.  Still it is hard to ignore when this amount of money is moving in your direction.  It is nice to know you are part of a positive trend rather than swimming against the tide.  I look forward to having you join us. 

Until next time.

A Moment of Clarity

This is not how we do business. 

Business people are idealized and vilified in equal measure.  For every Geroge Bailey there is a Gordon Gekko, I live in the world of business people.  I have been fortunate to know good business people and I have been cursed to work for a lot of the bad ones.  After a particularly bad day at the office, I sat in my cubical in utter misery.  It was what alcoholics call a moment of clarity.   I decided that I was going to become a business person and I was going to make sure that no one who ever worked for me felt as rotten as I did that moment.

This was why I founded E₃ systems.  I wanted to make business easier for other entrepreneurs by streamlining their shipping and receiving work.  I wanted them to have the power of a Fortune 500 company at a fraction of the price.  I also wanted the system to work over the web so that they could transact business away from the office and spend time with their family and friends.

It was a noble goal and we are going to continue to pursue it.  This week we are releasing another batch of improvements to Sully 2.0.  One of them features the ability to filter addresses so they are easier to find.  We are also coming out with a series of new videos which will show you use our systems. 

It is an exciting time and I can't wait to share it with all of you.

Until next time.

Business Should Be Easy

Find out how we can make business easier.

Business is a difficult activity.  Each day you are grubbing for customers attempting to improve profits and build better services.  So why are you spending your time rifling through paperwork?  This week we want to discuss paperwork and how we can help.

If you are selling goods and services you have to generate invoices.  If you are shipping goods you need packing slips and bills of lading.  Finally, all the goods and services require labels in order for them to make it to their customers via the mail.  Wouldn't it be nice if you could take care of all this without having to hire additional staff? 

At E₃ systems with our Sully 2.0 system does make this possible.  We also use Microsoft Tag technology so that you don't have to purchase expensive bar coding equipment and you can stay on top of what is going on from your office via a mobile phone, tablet computer or laptop.

We want to give you more time to spend on your business and your family.  That is why we created this system for you.  Business shouldn't have to be difficult. 

Drop us a line and we will contact you with more information. 

Until next time.

Fighting Code Bloat

Software Bloat is not pretty so why do we have it?

I have been working as a software developer for over fourteen years.  What surprises me the most is how complicated we make software for the public.  I blame two major constituencies for this trend.  First, software developers need to stop being too clever for their own good.  We need to concentrate on doing the same features better and faster rather than cramming more features into a software program.  This desire to have software do more is affectionately known as feature bloat.  More features are crammed into the same piece of software until it gets more confusing to use. 

The other guilty party is the business people who commission these bloated software projects.  Talk to any developer and you will hear stories of reports written for only one user of a system.  You will also hear stories of features added to systems to deal with one client or situation.  Additionally, features will be added to satisfy the political needs of an organization while not making software any easier to use.  Needless to say, these situations tend to drive software developers and customers batty because these additional features represent nothing but wasted time and money from the developer.  It also represents frustration for the customer as they attempt to use the software which has grown more complicated.

This is why when we founded E₃ systems we have made a point of trying to make the software as easy to use as possible.  Life is too short to spend time in training manuals and struggling to figure out how something works.  Many businesses do not have time to train their people so it is important that software is intuitive and easy to operate.  Most people just want to write out a packing slip or print an invoice.  You shouldn’t need a degree in computer science to make that happen. 

Our Sully 2.0 system makes it easy to do Bills of Lading, Packing Slips, Invoices and purchase orders.  Drop us a line and we will be happy to show you.

Until then I suppose you are going to have to suffer with bloated software.

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.

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.

New MSTag is Great News.

QR Codes are now a sexy addition to the MS Tag family.

I have spent most of my career working with Microsoft technologies.  I have experienced the good, the bad and the ugly over the years.  What strikes me is how much effort Microsoft has put into improving their products.  Visual Basic 6.0 is nothing like the present version and visual studio has come a long way since the 1990’s. 

In the eyes of some bloggers, my loyalty to Microsoft makes me a willing collaborator with an Evil Empire.  I do not see it that way.  As a .NET entrepreneur and consultant, Microsoft has kept me fed and the mortgage paid for over twelve years.   That loyalty has been returned when I joined Microsoft BizSpark.  For my new business, they have given me advice and guidance.  They have also provided me with licensed software to help me develop my on-line applicationservice – Sully.  It is a nice partnership and I hope it continues. 

This is why I am so excited about the latest news regarding the MSTag service.  Now products can be tagged with the standard MSTag, a QR code or use the latest technology from Android NFC.  It is a big deal because now you can be platform agnostic for 2D bar codes.  If you want to use QR codes tag supports it.  If you want stick with the MSTag format, you can.  Now a smart phone becomes the ultimate bar code reader and you will never have to purchase a bar code scanning system for employees.

This places E3 systems into an even better position to manage your inventory and logistics.  Thanks to MSTag any piece of paper can now communicate with your smart phone.  You can follow a bill of lading as it gets shipped and your sales force can learn in real time what they have in stock over their phone.  It is going to help you save time and sanity as you try to stay on top of all your merchandize. 

It is an exciting time and I am glad to be part of it.

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.

Making Sense of Agility

Just like dancing...only with business

In the next few blogs, I want to discuss the corporate values of my organization.  I have four guiding principles which shape how I want to run this business they are; agility, growth, development, and respect.  Today, I want to share with you my feeling about agility. 

In 2009 I was working for a dysfunctional family business, the technology staff was banished into the server room and was not allowed to do much interaction with the rest of the business.  When we were interacting it was usually to get reprimanded for not delivering what the rest of the business wanted.  It was like living in a Kafka story.  Introduced into this ugly environment was agile project management.  I was skeptical but decided to give it a try.  Much to my surprise, I liked it and I quickly became a convert. 

For those not familiar with Agile and Scrum, it is a better and faster way to deal with software projects created by developers and project managers at a ski trip in Utah.  They even have their own manifesto which is much easier to understand than the one Karl Marx cooked up.  It reads as follows:

·         Individuals and interactions over processes and tools
·         Working software over comprehensive documentation
·         Customer collaboration over contract negotiation
·         Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Thanks to Agile, it was now possible to put in place processes which helped the business user rather than get in the way.  Documentation is still necessary in Agile but could be changed to meet customer needs.  Changes no longer caused controversy because they were handled in a judicious manner.  Finally, developers and business users had to work together to get things done because they both depended on one another. 

In the course of developing my web application, I have made several major revisions to the product.  Each correction or improvement, never say change, did make the software better.  It also created an understanding between the developers and business users.  The developers set the deadlines for a project while the business users set the priorities of what needed to get done.  Each side had equal power and they both developed a mutual respect for each other’s challenges.  Best of all, we had working software which met expectations. 

In this business environment, being agile is going to be a competitive advantage as we strive to meet customer demand and make things happen.  I would rather have something people can use that is improving than vapor ware which promises to be perfect, whatever that means. 

Its All About the Business Plan.

As I stumble into the world of entrepreneurship, I have learned a lot about myself and business.  I have also learned how much work goes into a business before a single sale is made.  I put together a board of directors to help me avoid dangerous mistakes and they also helped me put together a primitive business plan.  For those Type-A personalities, the purpose of writing a business plan seems foolish; you have a product and sell that product to others.  The rest is just details.   

What I am discovering is that the devil is in the details.  Without understanding the details of your business or hiring people who understand those details you are doomed to failure.  I realized this when I was being asked questions about my market, what my competition was doing and pricing comparisons between myself and others.  I knew everything I needed to know about my business but nothing about the environment where it would work.  It was humbling but necessary. 

So I am back to the drawing board with my business plan and spending a little more time doing research on where I fit in on the business food chain.  I suppose by sweating the details now I can enjoy better sales in the future.