Lesson 7: No matter how similar a project looks like a previous one, it's not the same

Background

I’d like to share a story about failures I experienced as a software architect which taught me the lesson “no matter how similar a new project looks like a previous one, it's not the same.”

Several years back, I was a consultant, and I was assigned to a project for a legal association that was using technology to help its members. The organization wanted to integrate their SharePoint site with a product called Personify in order to provide single sign-on for their members.

Outcomes

I had previously worked on a project for another company that also integrated SharePoint with Personify. So, I thought I had a magic bullet. However, when I demonstrated the functionality to the client, they shared several expectations which I had not met: I missed!

Mistakes

I fell for the TIE IDIB blunder. TIE IDIB stands for “This Is Easy, I’ve Done It Before.” TIE IDIB is the mistaken belief that a previous solution will seamlessly solve a new problem with little to no effort.

Lessons Learned

We need to keep in mind that most organizations are unique from each other. Therefore, while some problems will shared from organization to organization, the set of problems within an organization is unique, and therefore the solution for that set of problems is also unique. We need to be careful about thinking we have a magic hammer because we inevitably start seeing all problems as a nail. We simply use our magic hammer to solve all the problems the same way.

While the knowledge I learned from the previous project certainly helped, the details of this integration were different, and therefore the solution needed to be a little different.

Agile Reinforcement

The Agile Manifesto reinforces this lesson with the principle “welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

Change is tricky. Often times, we like change, but we don’t want to be the ones to change. Change can be difficult for us to really embrace. So, we may want others to change or situations to change, but we don’t want to necessarily change that much!

We also need to be careful of the word “requirement”. Requirement is a tricky word because it implies that we somehow know what the customer wants. We usually don’t know what the customer wants. Heck, the customer usually doesn’t know what the customer wants. They may tell you what they don’t want after they see it, but knowing up front is something very, very tricky.

Eric Reiss wrote a book called The Lean Startup, and in that book instead of the word “requirement” he uses the term “hypothesis.” I really like this word. I think it conveys something that "requirement" sort of misses. An hypothesis implies “this is a best guess. This is something we think the customer wants, maybe they’ve even told us that they want it, but we’re going to measure it and verify it once we put it into production.” This term “hypothesis” I think more closely matches the spirit of what Agile software development is all about.

SAFe Reinforcement

From the Scaled Agile Framework comes a principle “assume variability; preserve options.” This is a really good reminder for us and one with which we can sometimes struggle. This is largely because when we start a project, we want to try to make decisions up front so we can get those economies of scale. It turns out those economies of scale are elusive for us, particularly in software development, and especially when there are a lot of unknowns.

Assume that your assumptions are wrong. How would you prove out those assumptions, right or wrong?

Assume that the customers are going to change their minds. How do you solicit feedback from the customer on what is going to change? What would they like to change?

Assume that your “requirements” are likely to change. How would you build things today so that you can change directions quickly in the future?

Assume that you will get better information in the future (because you probably will). What decisions can you reasonably delay today for a later date?

I hope my struggles and failures can help teach you this important lesson: No matter how similar a new project looks like a previous one, it's not the same.