Taking standardization too far

How far should you go?

There are ways to write software and ways to avoid.

As custom developers, my teams have written a lot of software.

Meanwhile, every time we bring new people on board, a question that comes to the forefront is “what is our way” to develop software.

Is it enough to say we are an agile shop, and XP happens to drive our flavor of agile more than SCRUM at this point?

What about the pieces of SCRUM we have appropriated as well?

What about the way we handle user experience, or document requirements, or resolve issues?

Being the same, being different

The more we follow “standard” methods, the easier new team members can join our teams, right? Couldn’t we just drop in a certified Scrum Master and all is well? (Well, not for an XP shop, I suppose.)

Meanwhile, the more we pick and choose what makes us most productive, the more we’re differentiated and the more we can produce competitive advantage through our processes, right?

I have been on too many methodology design projects, and I keep wondering why companies don’t just buy their methods like RUP, or just pick one and get a training company to have everybody start from the same page. (I know some do.)

My answer (to myself) is that though they would start with one way of doing things, they would soon be confronted with one of two options:

  1. Handle all sorts of exception cases and weaken the “standard approach”, or
  2. Even worse… they would cram all projects (and the people in them) into the same mold

From the same mold

George Dinwiddie’s weekend post on process standards triggered my thoughts in this area. It has also been triggered by the most embarrassing situation imaginable and my own rethinking of my offers to the market.

How does each person contribute to the team?

One of the most fundamental points in George’s post is that people have different strengths. They bring those strengths into a team environment.

In many cases it is difficult if not impossible to accurately distinguish the specific impact of each contribution to the team.

For example, the least productive developer is not always the one who completes the lowest number of story points in an iteration (e.g., if they invest in coaching and helping others).

The thing is, the more we use the same metrics for everyone, the more we insist on the same behaviors from everyone, the more we ask them indirectly to play outside of their strengths.

Meanwhile, removing them from the team could cut others’ productivity and ultimately risk project success.

In my comment to George, I mentioned three goals I had in identifying “our way” of doing things. Ultimately, they had to do with making it easy for people to fit into the team.

As I consider the potential negative side effects of removing individuality, I also wonder if too much standardization can be a trap, ultimately leading us away from the highly productive teams we are after???

Now, I could see how a very straightforward IT environment might do fine with highly standardized processes. It seems to me the more adaptive the environment, the more important playing to each team member’s strengths becomes.

So I have a specific question for you today – how much of my concern for individuality do you think relates to our work in custom software, and how much could apply to any situation?


Who struggles embracing unit testing?

Will unit testing "come back and slap us in the face?"

Today I want to share with you a blog post that I just loved reading over the weekend: “Why bother writing unit tests?” by Justin J. Moses.

Take a minute and jump to it… and then we can come back and talk a little more about what you have just read. (Go ahead… I’ll wait here.)

Thanks for coming back! First, let me start by saying I love hearing someone else’s history with unit tests.

The energy that Justin showed in writing about kicking and fighting his way into becoming an advocate for unit tests teaches me a lot about what people experience in adopting a new approach like unit testing.

A different story of unit testing

In the mid-90’s, in the advent of Java in the browser (think applets and Netscape Communicator), I was working as a consultant integrating testing methods into the development life cycle for Chrysler Corporation as part of their QS9000 standards initiative.

A colleague and I were building a software testing and certification lab, buying & developing custom tools for registering and certifying apps and designing processes for better requirements, traceability, regression, scale and load testing.

We had lots of toys to play with, but the one idea that resonated with me most during this period was that business requirements were getting transformed too many times before software delivery.

If anything could help us write better software it would be reducing those transformations and knowing that we ultimately tested what we wrote and that we wrote what our customer wants. Simple enough, right?

(By the way, across the cube wall from us was another little Smalltalk project for the Chrysler payroll folks… but that’s a story for another time… and perhaps one of the reasons I lean more toward XP… again, a story for another time.)

Some of the side effects of Test-Driven Development

So Test-Driven Development solved many problems for me. Closer linkage of requirements to tests, and the suggestion that if we preserve that linkage and stick to the scope of our tests… some really great side effects can show up for us, like:

  1. No gold-plating
  2. Successively refined coding, and not out of control
  3. Simpler code
  4. A discipline that supports true continuous integration (CI)
  5. Test failures (with rigorous CI) offer a laser-focus on what changed & who worked on it over a short time interval
  6. (and probably many more)

If the bar is green, the code is clean?

And with the release of xUnit frameworks to support building and automating tests it seemed to me like the answer to prayer! So I went into TDD and CI head-first, and therefore it’s good for me to carefully read and understand that not everybody has the same experience.

I make TDD and CI a requirement of my teams, among other practices… and so an understanding of the struggles people can face is also important if we’re all going to produce and write great software together.

What was your experience embracing unit testing… more like Justin’s or more like mine? Have you tried TDD or CI (not just an automated build/test process)? What struggles have you had? How did you cope with them?