The Daily Meeting 

First off, let me say that I dislike full team status meetings. Some people love them, I hate them. They can become huge productivity burns as an hour(s) evaporates from every team member’s work schedule. That said, sometimes a team meeting is worth the cost in time. The trick is to make the cost low and the benefit high. My solution to this situation is the Daily Team Meeting

The daily team meeting starts as soon as the team is all present. We keep it short, running around the room one by one giving a few minutes of status. It is also a time to share problems, new ideas etc with the team. Often in response to this sharing, another team member has knowledge or info to give back on the point raised.  If it is a quick response, we deal with it in the meeting, but if it is likely to be a longer discussion, we move on, choosing to follow up in a smaller group after the meeting.

As manager I guide the meeting and keep it on track. I confirm any status updates & plans with each team member during their turn. I also raise any team wide issues for discussion.

10 – 15 minutes, we are done! (FYI – My team has 7 members, not including me)  That’s pretty quick. I am convinced that we gain 10-15 minutes in productivity by having the team all being aware of what is going on around them and finding help from a teammate who already knows how to solve the problems that come up.

That’s is it, no other team meeting are necessary, unless a situation calls for one. No “one on one” status meetings. We are done!  Less than an hour a week typically and much more useful than the once a week hourly meeting because the information is spread out over the week and more current.

LEUTAM – pronounced "Loo Tam"

There was an article recently published about how middle aged persons, all over the world, suffer from depression in their 40s and seem to recover in their 50s. The researches who made this finding theorized that by your 50s, you become more comfortable with what you have than what you wanted to have in your 40s. In other words a person in their 50s had lowered their expectations about life to be more realistic and became happier as a result.

This is a great example of the L.E.U.T.A.M., Lower Expectations Until They Are Met, principle.

I know this might seem counter intuitive or like an endorsement of mediocrity, it its not. It really boils down to a “Haste makes waste” type of scenario. Let me explain.

Much of the Software Development Management process is about managing expectations of our customers and other stakeholders. We set deadlines for certain functionalities to be delivered with acceptable deployable quality and that becomes an expectation. If a software development team consistently hits their deadlines with high quality software they are heroes for meeting their deadlines. Miss expectations and you are viewed as “Under performing” by management and worse by your customers who were promised the new functions for their hard earned dollars.

In other words software development teams that meet their deadlines with the accepted level of quality they are good at managing and meeting expectations. They don’t necessarily work harder. The probably work less hard (That’s the point here), but are very good at setting reasonable expectations and communicating them.

So why LEUTAM?

There is a huge cost to setting expectations too high. Unreasonable expectations put pressure on the development team to produce more product features than is possible, leading to stress, short term thinking and degradation of the team’s morale. A team under schedule stress will keenly feel the pressure to meet the impossible expectations by cutting corners, working late (i.e. tired) and taking shortcuts that undermine quality in the effort to meet a date, so management feels there has been progress toward a project milestone.

Late delivery and/or poor quality obviously affect the customer view of your product too.  Based on poorly managed company expectations, the customer has been told of new product features and has developed their own expectations and made plans around these expectations. When a customer’s expectations are not met, it will impact sales as customers take their business someplace else. Worse they may spread negative “Word of Mouth” about your products and services.
 
Poor quality will not only negatively impact the customer, but will also impact the next project cycle as well.  Without the LEUTAM mindset, you will have a new set of equally unrealistic expectations to perform against, with the extra burden of building on top of poor quality code and poor team morale.

Missing expectations repeatedly causes a snowball effect leading to less efficient future development as the effects of poor quality and low morale compound on each project cycle. Instead of putting effort towards new product features, effort has to be spent on addressing bugs in the deployed products and refactoring of poorly written code. Because this cost compounds, recovering from this situation is very costly.

LEUTAM!!

Lowering expectations until they are met allows you to take the time to develop code in a reasonable time frame unhurried and unrushed. In software development, less is more. Well established realistic expectations will lead to proper development of quality software by highly motivated developers. Each future project release will be built upon a solid foundation making each development cycle more efficient. This is a great place to be when starting the next project, because most of your effort goes into new feature work. More revenue! Your customers will be happy too!

 © Don P. Gibson 2008

With 25 years of software development experience and more than 10 years managing software teams, I have picked up a few ideas that seem worth sharing. My hope is that maybe some of this information will make its way to Google and the other search engines where it can be found and be useful. I have worked for some world class companies and some real duds. In each case I learned a few lessons, some good and some bad.

I have a lot of experience building and maintaining software teams and perhaps that is where I will find most of my topics. Despite the ever increasing productivity gains made possible by new technology and methods, none will produce greater productivity than building a great software development team. The team is it. Good team, good software. Bad team, bad software. Sounds simple enough, but it took me years to discover ways to build great teams. I would like to share what I have learned.

Every once in a while, I come across a problem, to which no clear answer could be easily found on the internet. In these cases I will be inspired to share what I learned with the hopes others will find my efforts useful to their development projects. 

OK Who am I and why am I qualified to make these opinions? Good question.

I have been developing software for 30 years now. 25 years have been in professional development. I started my career training on “Big Iron” IBM mainframes and then right after completing a world class training program at a very respected company, I took a left turn and started working on PCs. PCs led me to a love of developing distributed systems. There is still something magic about reaching out across the net to fetch data from someplace elese.

I am currently employed with a company, a leader in their industry, that provides websites to a specialty market place. Our facilities host around 30,000 web sites. Each of these sites is generated by our framework based on Microsoft .NET technologies. We handle a staggeringly large amount of volume and huge data sets.  We have a legacy system built on .Net 1.1 and a more modern code base built on .NET 2.0. And we have a legacy custom built CRM system also based on .NET 1.1. And... some really old Classic .ASP. We have it all!

I came into the company about a year ago after the former Development Manager had left in frustration and had actually been gone for some time. Most of the code was developed before I arrived, but I have overseen the development of our newest applications, bug fixes and re-writes.  I am “hands on” and have worked with the code first hand.

My company's code bases were written by several past teams, no longer present.  These teams, to be fair, left us with a terrible legacy of code. The net result of this is that the present team has inherited a real mess!  The present team has also re-written much of this legacy code using more modern techniques and with an eye to much higher quality.

Living and breathing the problems brought on by this legacy and watching over the effort required to replace it I can contrast it against the new modern code base. It is a real opportunity to see how much extra work bad code and techniques creates. It is my hope that I can relay some of my real life experiences in a way that is constructive and informative. It would be easy to descend into a "Bitch fest" mentality complaining about my job, but I don’t think that would be any more interesting than millions of other personal blogs. I am aiming higher. :)

I welcome comments to my thoughts and opinions. I don’t hold that my writings are perfect nor always correct. They are thoughts and opinions that I hold. Take them for what they are worth and if you want to contribute, please post feedback or write to me.

Lets get going....

Don 

Visit My Sponsor

Crawlers, click here so I know you visited me.