IT perspectives: Strong indications you are NOT getting it (Agile)

I have had some time lately to think about the state of development in many companies today and decided it would be a time to start talking about some of the clues I see in organization after organization that they are not quite getting it. When I say getting it, I mean they have adopted the correct path, but don’t quite understand the paradigm.

Paradigm shifts are natural parts of innovation. When someone truly looks at anything from an innovative perspective, it almost always requires throwing away old thought patterns and shifting to a new way of looking at the world. In Microsoft development, the shift from COM >> .NET (and especially ASP >> ASP.NET) required a huge paradigm shift in thinking. Unfortunately, it was still possible to hang around your old “loser friends” and not make the shift. And, it has served me nicely, as I have cleaned up a great many ASP.NET apps that were actually ASP written using ASP.NET tools.

In this post, I would like to focus on some key clues that you are not “getting it” in Agile development.

Agile Development

Agile is the buzzword everyone wants to hang their hat on. You see job description after job description touting Agile. But when you get engaged with a company, you find many of them are not really doing Agile, and most are not doing Agile well. They are still working a waterfall methodology with a bit of time boxing, some stand up meetings, and other artifacts of one of the Agile methodologies. When you examine closely, you find very little that is Agile about their implementation of the methodology.

As an example, let’s look at the average corporate entity that adopts Scrum. They will generally bring in some consulting firm to teach them the artifacts of scrum, adopt a scrum template in Team System (assuming Team Foundation Server is their source repository), and start having sprint kickoff meetings, stand up meetings and burn down meetings. They will start talking about chickens and pigs and adopt the nomenclature of Scrum. But, they most often don’t really “get scrum”. Here are a few common clues that they don’t get it.

Developer Interruptions During the Sprint

The idea of time boxing an iteration (sprint) is to keep developers active and on task. The limited time for a sprint (2-3 weeks in most companies) means you can adjust priorities rather quickly, but adjusting in the middle of an iteration is wrong. In the waterfall methodology, it was often necessary to stop a developer or a team and move them to another task in midstream. This was due to the all or nothing nature of the waterfall methodology. As business changed, you often needed to change priorities and since everyone was in a long term stream, you had to dam up the river and get people going down side routes.

With Agile, you are, at most, a few weeks out of changing developer priorities. The only reason you should have to stop an iteration is you find you are building the wrong software. And, if that happens, you failed to plan, which means you planned to fail. It is expensive to interrupt a developer on task.

Once you adopt an Agile methodology, the PM part of the team should not only be managing the plan (through standup meetings), but also keeping ahead of what is going on in the next iteration. This leads us to the next clue an organization is not “getting it” when it comes to Agile.

Meetings that Take Too Long

The goal of a standup meeting is to get a status update and determine future flow. The format is:

  1. What did you get done since the last meeting?
  2. What are you going to do before the next meeting?
  3. Do you have any impediments?

So one developer’s contribution might go like this:

Developer: Yesterday, I got the menu roughed in, but I still have a bit more work to get it done. I am having a strange problem getting the site map to work and some nodes are not showing up.

Scrummaster: John has experience with the site map and some of the problems associated with it. I am going to have him pair with you for a couple of hours this morning and get through that roadblock.

At this rate, you can burn through the entire team in a matter of 5 to 10 minutes on most mornings, with a few extra minutes if you have to figure out who can help on a particular task. You will note that I have taken the assumption the shop does not pair program 100% of the time. I have done this, as I find few shops that have completely bought into the idea of pair programming.

By the same token, the sprint kickoff meetings should not be all day affairs. If your PM guys are one iteration ahead, then the kickoff meetings should be more focused on doling out the tasks than determining what tasks need to be done in an iteration. Certainly some new tasks may have popped up, but if the meeting is an all day affair, you have failed to plan again.

Throwing Code Over the Wall

In many traditional shops, it is quite common to see developers as people who develop … ONLY … and the QA team as the testers. The problem with this approach is you often see code with very bad flaws that should have been caught by dev pitched back over the wall by QA. You end up with this ongoing volleyball match where the code is the ball and the developers and QA people are the players. It is completely non-productive.

From the development side, you should be able to determine that your software is really working before sending to QA. This is done through unit testing and ensuring proper code coverage. With .NET 4.0 and Visual Studio 2010, there is a new tool called Pex (and Moles) that can be used to fill out code coverage with fringe conditions, so we have less and less excuses to not code tests. Add tools like Code contracts, and you not only end up covered, but you run the gamut when it comes to expressing intent of the code. It is fine if you do not practice TDD (some purists may cringe at that statement), but it is not fine to leave all of the testing to QA. Their job is quality, which means catching the conditions a developer might not think of, not testing to see if you actually did your job.

You have to decide whether you want to be a computer artist or a computer scientist. Anyone who codes blind, without proper tests, is practicing a form of computer art. One might even say voodoo art. In order for coding to be science, you have to have proof the code works as expected. Let’s delve into this with something personal for me.

In 2007, my youngest daughter was diagnosed with cancer. At 3 years old, with non-metastatic Ewing’s Sarcoma of the soft tissue, she was in a group where 100% of the participants who had her treatment protocol lived. The problem with taking that as a scientific fact, is the group had only 4 members, which makes it, statistically, insignificant. The larger group, which was statistically significant, had about a 70% survival rate if it was non-metastatic down to < 20% if it had metastasized to the lungs.

If we take this back to software, creating a small app to run the methods, or even adding a single test to significant methods, is better than nothing, but it is statistically insignificant as a measure of code quality. To have a proper method, you need high code coverage, at minimum, and preferably tests that hit fringe conditions. Without these tests, you are blindly asserting code quality … and most likely wasting both your time and that of QA.

Final Words

I would like to say the above points represent the exception rather than the rule, but that is not my experience. More often than not, people DO NOT get it, especially when there is a rather large paradigm shift in thinking (waterfall to Agile, for example). Some may argue that not “getting it” is less damaging than not “moving to it”, but I am not convinced that is always true. Sometimes bad Agile practices (waterfall mentality with an Agile methodology) are far more damaging than sticking to a waterfall methodology.

This is a good start on some of the practices that show an organization is not “getting it”. Other topics we will explore are not getting the paradigm shift from ASP to ASP.NET (or COM to .NET), not getting applications, and the like. I had envisioned getting into one post, but I need to keep this to few enough words that people will actually read it. 🙂

Peace and Grace,

Twitter: @gbworld


2 Responses to IT perspectives: Strong indications you are NOT getting it (Agile)

  1. denise says:

    Good article. I have experienced all of these things. I have learned the hard way that throwing code over the QA wall without enough unit tests or UI tests can be a painful disaster. It creates a very un-fun volley ball game that wastes time for all involved. One could only guess at the statistics but I would say 80% of shops that say they are using Agile are really using time boxed water fall methodology. Agile gets a bad rap at times when Agile is not the problem.

  2. Gregory says:

    Denise:Very true about the volleyball game from Hell. And I have seen time-boxed waterfall, as well. When the sprint kickoff takes more than about 2 hours, you have not time boxed properly. A standup meeting more than 15 minutes shows the same issue. But change is hard for most people.Peace and Grace,Greg

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: