You are currently browsing the tag archive for the ‘agile software development’ tag.

holiday1Although I’m usually pretty disciplined about diet and exercise, I tend to slack off quite a bit during the holidays. Some believe that a vacation from discipline is a good thing every now and then, while others feel that “discipline debt” becomes hard to pay off.    I do know that losing the 5 pounds I’ll probably gain is going to be a hassle, and completing my twice weekly bike rides is going to be more difficult when I resume.


Many projects (Agile or not) tend to go on vacation during the holidays.   Not necessarily a full blown stop, but work may slow to a trickle.   Many will take days off and/or participate in other non-project related activities.  When a project team is shut out of office decorating, food-fests and gift exchanges, discontent can build.   


When planning a sprint that will span holiday weeks, it’s important for the leadership to agree on an acceptable velocity that could be lower than previous sprints.    This strategy continues to enforce the discipline of “we set a goal and work together to meet or exceed it.”    The alternative is to miss an unrealistic goal and blame it on the holiday.   Allowing this can open the door for all sorts of other excuses down the road.


Another strategy is to devise a holiday sprint – one focused on cleaning up outstanding housekeeping items that would be nice to get out of the way.   Items selected for the holiday sprint are hand picked based on size, complexity, and lack of dependency on resources who will be gone.  Although this may violate the practice of driving sequence based on priority, it does allow the discipline of the process to endure.


In a perfect world, members of a newly formed Agile team are highly skilled, and the role of the coach is to overlay Agile so the skills are employed in the right way, in the right place, and at the right time. But many of us don’t live in a perfect world.

As a coach, I have often been challenged with team members who lack fundamental software development skills. This can distract efforts to be successful with Agile…and when core skills are missing, there is risk that the organization will peg Agile as the culprit for poor results.

I have met a number of people who told me that Agile was abandoned at their company and dubbed a failure. Agile cannot ‘heal’ poor software development skills, rather, it helps teams that possess skills experience an order of magnitude improvement in results.

When tasked with coaching a team of underdogs, the first order of business is to assess the presence (or lack) of core software skills. If an underdog team is what it is, a successful coach recognizes the obligation to clearly separate Agile coaching efforts from those of teaching/mentoring fundamental skills. This will help a company balance it’s needs: To emphasize skills development, or to place more emphasis on successful delivery. If the latter is the emphasis, it may not choose to pursue that particular project with a team of underdogs.

A few years ago I managed a team of learning content developers for an international consulting firm. One of my many trips brought me to Paris, France to check on the progress of a course being developed there. One of my friends and colleages, Thierry, honored my visit by organizing a dinner for some of the employees and their spouses.

We went to a hotel at Versailles and were seated at a large round table on the back patio – I think there were 12 of us. It was a beautiful summer night, and everything was perfect. The food was great, and everyone was chatting up a storm, so all seemed to be having a good time. In the midst of the chatter, Thierry shouted, “Hey everyone, you’re all speaking in French. Ken doesn’t speak French, so please speak in English.” I was a bit embarrassed, and I can imagine that some of the wives may have been thinking, “The lazy American comes to our country and he can’t even speak our language.”

One of the wives said out loud, “But why? We’re not even talking to him?” Although everyone laughed, she made an interesting point which begs the question, “What would have been the point of me hearing all those conversations that I wasn’t intended to be a part of?” I believe that in an informal setting like this, people are expected to eavesdrop a bit and jump in and out of conversations at will.

Recalling this story caused me to think about all the collateral and indirect communication that occurs in a team room. At times, the dynamics in the team room involve any number of impromptu conversations. Often times, others could contribute to (or learn from) those conversations, even though they didn’t receive an engraved invitation to participate.

The informality of impromptu conversations includes an implicit invitation to tune out, listen, or jump in fully and contribute. I contend that much of the high value communication that moves a project forward occurs this way.

I’m not frustrated by Brett’s comments about assertions in my Blogs. I’m actually flattered, and happy that he’s reading them. Tenure doesn’t necessarily earn me any more credibility than smart successful people with fewer years of experience.

My eclectic undergraduate training (Mgmt Science/Operations Research + Psychology minor) augmented later by an MBA illustrate where my interests lie. I’ve always been a fan of Franklin and Lillian Gilbreth’s time motion work in the early 1900’s, and later of Goldratt’s Theory of Constraints. On the other hand, my interest in Psychology and Sociology tends to clash with the concept of applying a pure process optimization approach to software development. I’m further fascinated that software developers took so darned long to pay any attention at all to those old proven methods. It’s all these things that I find so fascinating.

When it comes to human behavior in a social environment, there are few wrong answers. There are far too many uncontrollable variables to be able to treat human processes as a science. I am fairly certain that most humans don’t want to be cogs in a machine. Even those who are willing to be cogs will probably dislike it after a while. (Then again, I’m sure you can’t say that about everyone.)

I do agree with Khan that lag time is the primary cause of delays on projects. (btw – per your comment, I updated my blog with a link to the referenced work.) The Ops Research bug in me says to attack the lag time to compress the duration of work. The Psychology bug in me tells me to evaluate the personal motivations and interactions that cause people to do (or not do) things that waste time. And the MBA bug in me causes me to look at projects from a purely P&L and ROI perspective. I believe that proper balance of all three perspectives will lead to true optimization.

For folks in Texas and the surrounding area, don’t miss out on a great free learning opportunity about Agile development with .NET. The event is on Friday November 14 at the Microsoft office in Irving. Improving Enterprises is proud to sponsor this event with Microsoft. Again, it’s free of charge, but you must register ahead of time if you would like to attend. To see more details about the event, and to register, click here.