Agile Practices that Tend to be Problematic

As I have mentioned before, I attended a breakfast talk by Steve McConnell ( entitled “Legacy of Agile Software Development”. During the talk, Steve skipped over the section of the slides labeled “Agile Practices That Tend to be Problematic”. I grabbed the slides after the presentation to see what he had to say.

Note: Steve is not necessarily saying these are bad — just that the teams his company has evaluated, these practices have not provided the value that they promise.


  • System Metaphor – Least understood practice
  • On-Site Customer – Difficult to achieve
  • Collective Code Ownership – Uneven code quality and sometimes results in lack of ownership.
  • Pair Programming – Sweet spot between junior and senior programmer
  • Refactoring – Good practice whose name is used to cover up bad behavior

Creating Opportunities to Incorporate Change

I attended a breakfast presentation by Steve McConnell ( entitled “Legacy of Agile Software Development”. A phrase that caught my attention was “creating opportunities to incorporate change”.

As we all know, The Agile Manifesto ( states valuing “responding to change over following a plan”. Steve’s presentation summarizing agile values had “responding to change” struck out and replaced with “creating opportunities to incorporate change. This struck a chord with me. I have seen many teams that call themselves agile (although I would argue that they were not…) who were resistant to responding to customer requests. Usually, they delay the request stating some rule of the methodology they are following. Almost always, the methodology would allow them to respond to the change — “create the opportunity to incorporate change” — yet the team resists. You can lead a horse to water but can’t make it drink.


Lessons from Improv

Last week, I attended an ASQ dinner meeting where the speaker was Izzy Gesell ( The title of the talk was “Tools for Transformation”. I think I would have named the talk “Lessons from Improv”. Izzy is a former improvisation artists and he applies the lessons and techniques from improvisation to the business world.

Izzy’s talk was dynamic and interactive. I took away 3 items which can be applied to a software (or any other) team:

  1. Acceptance – Accept what is given and move forward
  2. Focus – Concentrate on the essential
  3. Trust – In the process and the people

The idea behind acceptance is instead of complaining or trying to change the unchangeable, it is more productive to take what is given and move it to the next level. This does not necessarily imply agreement. Concentrating on the essential – Focus – I believe is a key attribute of all the successful teams I have been a part of. In the case where the team was not performing well, a lack of focus was definitely a component. And finally trust. Once again, the best teams operate in a an environment of trust.


Error Seeding as a Humbling Experience

As I have mentioned before, I recently read The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas. One of the tips is “Use Saboteurs to Test Your Testing”. This reminded me of my first encounter with error seeding.

While working on my Masters, I took a software testing course. I had been working on test teams for several years so I felt confident coming into the course. We were asked to take a program we had written in a prior course to use as our case study. We were asked to create a suite of tests for our program. I did so and discovered several bugs I had not identified when I turned in the program. Overall, I felt very confident in the test suite I had created. Throughout the semester, we would apply the various concepts we were learning against the program we had selected.

When the concept of error seeding was introduced, the teaching assistant (TA) for the course took our programs and introduced some errors into them. She went through quite a bit of work. Some errors she introduced were simple to create – for example, changing <= to <. Others were more subtle, such as introducing a side effect into an existing method that had no side effects before. We were given new binaries and told to run our tests and submit the results. (We were not told how many errors were introduced into the program.) I ran my suite of tests -- all automated by now given the fact that this was an ongoing project. Sure enough, my tests discovered 3 changes in behavior. I felt good about the results. Then we were told that each program had 10 errors in them. I was humbled - and learned a lot by examining what my suite had not found.


Personal Worklog

Years ago, I was stuggling to meet all of the committments I had made. When discussing this with my manager, he suggested keeping a log of what I did each day for a couple of weeks to identify items that I could eliminate or postpone (or now that I manage others – delegate). The exercise was useful and got me through the commitments. I then promptly forgot about it. Some time later, I was in a similar situation and started to keep the log. This time, I made it into a habit. Since then, I have kept a simple work log at my last 3 companies.

It is a simple format:

Date      * Description of what I did
Date      * Description of what I did
Date      * Description of what I did

No more than a line for each item. (The details can always be found in my engineering notebooks, wiki entries, source code control comments, bug reports, etc.) At the end of each week, I archive that week’s log and start a new one. I review the prior weeks log when I file my weekly status report. At longer intervals, I will review larger blocks of time.

The work log has helped me numerous times. It is especially useful when I need to answer questions like “when did we do A, B and C?”

I am currently in the process of moving out of my current position. One of the first things I did was review my work logs for the last 12 months and identify

  • What types of items should my replacement do?
  • What should be delegated to existing team members?
  • What items do I need to discuss with my boss about who should take on these duties?
  • Without these logs, I am sure I would let something slip through the cracks. This is definitely a habit that has been useful and that I will continue.


    An Example of Accidents of Implementation

    As I have mentioned before, I recently read The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas. In the section on “Programming by Coincidence” I was reminded of a bug I found, it was fixed and it broke a customer’s implementation.

    The product was a set of tools, services and application servers that a client could use to automate some processes in a particular vertical industry. As part of the product, there was a full programming language. I came on board to build the test team. As we moved forward with new functionality, we slowly worked through the functionality which had never been formally tested before. When we started testing the date arithmetic functionality, we found quite a few errors.

    One of these errors was the “add” function would accept blatantly invalid dates. When this error was fixed, we verified and moved on. It ends up that the biggest customer used the “accident of implementation” of the add function to determine whether the current year was a leap year or not. They would add the date “February 30” for the current year with the value 0. The system before the fix would return the last day of February (28 or 29 depending if it was a leap year or not) for the year in question. After the fix, the system would return an error. (Sometime before this bug was fixed, an isLeapYear function had been added to the system but that was after the customer implemented this code.) The customer’s developers had used this accident of implementation for some crucial logic in their application. This behavior was not documented – someone had “discovered” it.


    Personal Status Reports

    Over the years, I have seen many forms of status reports used by my team and the teams I have worked on. (I am distinguising these reports from those used for project status. Often, there may be corporate standards or contractual requirements associated with them.) I have settled on the following format which works well in a variety of submittal formats (email, word document, wiki, etc.):

  • Notes
  • Highlights
  • Lowlights
  • Plans
  • The notes section is optional. It is used as a reminder of upcoming items or circumstances that the manager should be aware. I have used it to record upcoming vacations, travel plans, customer visits, release dates, milestones, etc. This section often spans multiple reporting periods. The highlights section enumerates those items that went well during the reporting period. These are just bulleted lists – not a lot of text. The lowlights section are those things that did not go as planned. Once again, it is just a list of bullet points. The plans section lists what the individual intends to accomplish in the next reporting period. If this information is captured elsewhere, say in a project plan, then just reference it.

    I use these reports in two ways. The first is in my regularly scheduled one-on-one meetings. I review the status report beforehand. (I am opposed to receiving both written and verbal status.) I make notes of those items I need more information on – these are usually the lowlights. I encourage my staff to include items in their reports that they want to discuss with me. The second way I use these are during performance reviews. This is especially useful in countering the “recency effect” – only remembering what has happened in the last 1-2 months. Unfortunately, it is usually the details of the good things I forget, so I review the highlights sections in detail for the last year. I only look for trends in the historical lowlights.

    I have used this format consistently over the last 3 years. As an organization, we have tried collecting different information or collecting it in different ways but I keep coming back to this format.