A recipe for disaster

.
I have worked at several companies throughout my career, which wanted to move from a waterfall methodology to agile methodology, and each has had its own unique set of problems. Even though they are different, I have notice similarities as company have tried to move in the direction of agile and the best way to describe them is by using the analogy of remodeling a house. It seems to be a best fit when describing the situation in software development.

In this analogy our faithful customer has a conversation with the architect who writes downs the customer’s ideas and formulates a plan to create a thing of beauty for the customer. When presented to the customer there is the normal back and forth discussion until there is agreement that what the architect has come up with matches the ideas of the customer. The architect takes the customer’s requests to a meeting with the drafters, the construction team, and the inspector and presents his vision of the additions and enhancement the customer is expecting in the near future.

The drafters and the inspectors take time to go over the ideas to achieve clarity on what is really needed to meet the customer’s desires. As the construction team begins this process the superintendant of construction says to the team we don’t have time to go over the architect’s proposal because we have too many other projects that need to be completed, first. So months goes by with no input from the construction team, until one day the architect inquires as to the progress being made on the customer’s request. The superintendant replies since the proposed project has not gone through the proper vetting process that the construction team had not even looked at the request and had no idea as to how long it would take to complete the additions and enhancements.

So after having the new process explained, the architect reworks the customer’s request and submits it into the process expecting a reply in a couple of weeks since that is how long the process is suppose to take. Two months later the architect is given a draft schedule and an indication of how long it would take to deliver the entire project. The end date is unacceptable to the customer, so negotiations on the scope of the project begin with an end date in mind the project’s scope is cut in half, though the architect is not happy, the architect needs to get something completed by the end date, and reluctantly accept the new plan.

The plan is put into action but to ensure the schedule is met, decisions that the team of drafters, construction workers, and inspector usually make on the fly for quick turn around, is now delayed as each decision must be estimated by the construction workers and than vetted by a committee superintendants in a weekly meeting, and can takes weeks to decide if a change can be made and its effect on the schedule.

When the end date arrives, there is much bickering, finger pointing, and blame being tossed around as the incomplete project is delivered to the customer. A root cause analysis is conduct to find out why the project failed, but it is not done using the 5 why of root cause analysis and blame is fixed on individual department and the results of the analysis is never seen by the parties involved. As a result of a superintendant wanting to make a point to another superintendant, the delay in beginning of the original project created a crisis at the end of the project.

The moral to this story is for superintendants to get out of the way and let the work progress, because everyone loses, when superintendants think more of their egos than they did of the project at hand. In an agile environment, egos have no place that the table and when the egos appear a recipe for disaster is beginning to cook.
.

Working for the Village Idiot

-

In medieval times there were people who were cast out, despised, ridiculed, and mocked; these people were commonly known as the village idiots. Where are these village idiots in our communities today? It is my contention that they can be found in the ranks of the middle management, known as the team lead, playing at shift supervisors, even pretending to be the front-line supervisor, or even the department manager. The pointy haired manager in the Dilbert comic is one image of a modern day village idiot, due to the chaos caused by his fascinating management ability. The modern day village idiot can be defined as a person who is known in their community for their stupidity and ignorant behavior; in this case the community is the office, and everyone usually knows who these people are, and try to avoid working for them as much as possible. But there is always the chance you cannot avoid the privilege of having to work for one or two.

At a company where I was working the following email was sent between a team member and the team lead: team member -“I was just looking at the milestone document and have noticed we only have 13 working days before this application should be completed and we are far from being near completion. I was wondering if we are going to meet this deadline. Or has the deadline been postponed? If the latter, what is the new date? If not what do we need to do to meet the scheduled date? I’m just curious; let me know if there is anything I can do.” The response is classic, a real gem; the team lead, bless their simpleton soul, replied “We can only test what we have been given. Thanks for the concern”. Is there any better answer that could have been given? I think not, the clarity in which each question was handled, the clear direction which was given, and the listing of the abundant opportunities which needed to be handled before the deadline, surpasses anything that could be imagined. Is avoidance to answering questions a typical village idiot reaction? I think so. I believe that the village idiot gets so confused when questioned that they say the first thing which comes to mind.

A friend of mine was called into his boss’s office where his boss informed him that he was being charged a half day of PTO (paid time off) for the previous day. It seems that after working 10 hours my friend left for the day at 2:30 p.m. Since he left before 5 p.m. the boss had to charge him for a half of a day PTO. In defending himself, my friend told his boss that he did work a full day and argued that he should not be charge the PTO. In another classic response this manager, bless their simpleton soul, said “I worked here for four years before I took anytime off.” Boy, what a reason, because I am a village idiot, you must be one too. Oh by the way I’m the boss so I will punish you for being more intelligent than me.

How do these people advance to such levels of responsibilities? I honestly believe that the Peter Principle – where an individual is promoted to their level of incompetence – is alive and well in corporate America.

So what does all this have to do with software quality assurance? It is that we all have known or have work for the village idiot. So how do we deal with the village idiot? Well, you can pick on them behind their back, when their not snooping around trying to figure out whom you’re talking about, which they always think is them. You can involve them in your group and let them be the court jester. You can even take the time to get to understand them – my wife would be proud of me for suggesting that one. You know that rule you were taught as a kid but seem to forget as a teenage and are reminded about it as an adult as you teach your kids, yeah that’s the one “do unto to others as you would have others do unto you."

Since there is only one way to survive the village idiot, sit back, relax, and just laugh. Enjoy the adventure because the village idiot will do something else tomorrow that will make you shake your head and question your sanity.

.