Agile is Relationship Management

Upon reading a recent article about “Never Trusting a Client’s Initial Requirements” we just had to write something in response. This particular article comes from the traditional project management camp and contains some pretty good points when undergoing initial requirements phases with a client.

While the author, Brad Egeland, makes some good points, it is apparent throughout the article that an Agile approach to requirements gathering sessions is really, in the end, the best answer.

Brad suggested four ways to elicit further requirements from the client, including:

  1. Hearing the customer out – Making notes of the client’s needs and asking the right questions.
  2. Meet with SME’s and end users – Gathering different perspectives on the requirements.
  3. Rework the requirements – Make necessary changes from the original requirements document.
  4. Give the client the bad news – Tell the client that they got it all wrong.

Wow. Doesn’t sound to appealing, right? We didn’t think so.

So what happens if the client won’t budge? Brad tell us that:

“I believe that, in most circumstances, ending the relationship at that impasse rather than risking permanent damage to your reputation is usually the best path to take.”

Excuse me? After all the work and effort you’ve put into the requirements process and setting up meetings with various stakeholders and SME’s and then doing details re-work of the original requirements, you’re telling us that we should sever the relationship? Are we reading this right?

The rationale that Brad suggests to the reader is that the individuals reputation is at stake. We understand that, completely. But how is this relationship-ending process beneficial to anyone?

Here is where Agile really shines.

What makes Agile software development processes so unique and successful is the collaborative nature of the product building and product requirement phases. You need not sever a relationship with a client merely because they won’t budge on the requirements. You have a conversation about features, broken down into functional units of work. You work with them through iterative development which allows consistent feedback loops to allow for changing requirements. Need we say more?

Agile allows situations like these to be a turning point for success:

  1. Work with the customer through discovery and story carding sessions.
  2. Break down requirements into features that can be released iteratively.
  3. Meet with the customer weekly, if not daily, to discuss changes.
  4. Show the customer demo-able product early and often.
  5. Allow them to make changes to requirements at any time and communicate the down-stream affects.

Severing a relationship with a potential client or customer is never a way to go, especially after all the hard work that has been put into the requirements up front. Take a stab at Agile software development processes and see how you can make these potentially negative encounter into opportunities for success.


7 Replies to “Agile is Relationship Management”

    1. Completely agree. It’s a current state. Tomorrow may change. That’s why we must have the conversation, if not daily, with the customer. Doesn’t have to be formal, but it has to be constant.

  1. I’m noticing with a client right now that the constant shift in requirements is causing over-analyzing by the team and almost paralysis from going certain directions over another maybe faster solution.

    When you have constantly changing requirements and you are also trying to “Show the customer demo-able product early and often” at what point are you showing them their changes in the iteration?

    1. Great question. Let me see if I can break down what you’ve asked here:

      1. Your client is having shifting requirements.
      2. The development team is open to those changes.
      3. The team wants to demo a product early and often.
      4. So when does the client see the changes?

      Requirements changing isn’t a problem. It’s a matter of having a conversation with the client about what is accepted and ‘locked’ into a sprint or so. What you do want to do is let the client know that these changes won’t happen overnight and won’t probably be seen in the next demo.
      But if prioritized correctly, they can be seen in subsequent releases.

      You need to have a well defined product backlog and list of features that the client wants. After having these conversations you can map out what is do-able within a certain time period, and any changes during development will go into the next batch. Your developers need to have leadership that allows them to focus on a set number of features for a release and not have to worry about having the priorities change mid-sprint. Let them focus on the pre-defined set of features and the next changes will go into the next release.

      Does this make sense?

      1. Definitely makes sense. I think bulk of the changes are coming from not having a “well defined product backlog and list of features” and decision makers missing the early reviews of the product.

        Back to the relational side of dev and pulling them back into the conversation. Thanks for the reply.

        Merry Christmas!

Leave a Reply