Now That I’ve Seen It…

“Now that I’ve seen it…” is an experience we have all had in life. And most of us have had that experience as makers, customers and users. We think we know what we want or need or have to create to solve some problem. Then we get it, see it, use it and things change.

No matter your context, when you are a member of a team tasked with solving problems for people, the receiver of that solution will inevitably have a revision to what was delivered once they get their hands on it.

A recent non-software experience also matches this. Remodeling a bathroom, the initial tile floor went in, upon seeing it, my wife and I said “Now that I’ve seen it…” and we made a change to a different tile. We are much happier now.

This same scenario plays out in the software world weekly, daily, or hourly if you are good or lucky. We have an understanding of a problem, or at least we think we do. We build a bit of software to solve for this problem. Upon delivery, when our software is actually useful, we obtain rapid feedback. This feedback is, at least in my experience so far, met with, “this is great, but now that I’ve seen it/used it…” <insert change here>.

This is not a bad thing. This is a great scenario. Some people view this as “missed requirements” or “rework”. And for those, you probably have some of these commonalities:

• Large batch releases after months of coding and testing.
• Silo’s between product, engineering, testing, customers and users.
• Whisper down the lane user stories filled with assumed design solutions in the form of written requirements.
• Hard time deadlines.
• Hard cost restrictions.
• Fixed scope.
• Stakeholders over ruling customers or users needs.

These cause pain in the “Now that I’ve seen it…” scenario since it would also require large batch changes. Or at the very least, there would be substantial interrelated changes needed. Excessive meetings to “get aligned”. Finger pointing about the “specification details in the requirements”. Working excessive hours due to the fixed deadline, cost and scope.

What causes the “Now that I’ve seen it…” scenario. I think it is communication or lack of communication. And also the fact that people don’t really know what they need until they experience it. On the communication side, we are not achieving a shared understanding. But how can you be sure you get that shared understanding? I have found some tools that help. Story mapping, mock ups, workflow diagrams all created with the people needing the software and the people creating the software working together. Even with those, “Now that I’ve seen it…” still happens. Because having something tangible to use and using it usually sparks new ideas or changes. Until you finally reach the state that it is what is needed and you can move on to the next most important thing.

There is also a process known as Dual-Track Development. I have worked with this process before and utilizing the core team approach has been very beneficial for communication and shared understanding issues. The “core team” is typically 3 people. A product person or customer, an engineer, and a ux person. These people are focused on the value, feasibility, and usability of building that software. One modification a couple teams have done was add a qa person to focus on a quality perspective during this discovery and design process. Everyone has their own way of using this type of approach.

By far the greatest experience I have had to solving the communication problem is mob programming with actual users available to look at the software as its created. XP mentions this novel idea as On-Site Customer. The “Now that I’ve seen it…” happens during the creation of the software. We build a little with the customer/user in the room or on the zoom. As the software comes to life, these customers and users are able to steer the solution. I would highly recommend reading Mob Programming by Woody Zuill and Kevin Meadows to get you started.

Communication has been a problem for a very long time. Communication is complex verging on chaotic. How do we know our message was received? Was our message received as intended? Will our message circulate our team, org, or possibly the world without the wisdom to put it into the proper context?

That last question is my favorite to think about at the moment. I think this is why we find issues with how the Manifesto for Agile Software Development, XP, or Scrum for example are implemented and used. Before diving into this, I should acknowledge some bias. I don’t particularly care for Scrum, or any other framework for that matter. I think Scrum as defined in the Scrum Guide as of 2020 is mostly harmless. However I do not think it is an agile approach to software development. It feels very prescriptive and rigid and that hinders your flexibility. But again, that is not limited to Scrum. Any framework that tells you exactly what to do and when to do it does not seem very agile to me. With that in mind, let’s use Scrum as an example of communication failure.

Scrum as intended vs Scrum as normally implemented. People do things and attribute them to being a part of Scrum that are not mentioned in the Scrum Guide. This is both good and bad in some cases. Stories are not mentioned in the Scrum Guide, but people still use them with Scrum. I think that is a good thing. Provided the user stories are not just the same old requirements spec docs of old. I like working with user stories. I like thinking about the problems we are solving from the users domain perspective.

Also, estimation is not mentioned in the Scrum Guide, but people still use story point estimation as a needed practice using Scrum. And frankly, unless you are trying to sell me something estimation does nothing good for anyone involved. Estimation is dangerous. The people creating the estimates are guessing and are typically uncomfortable with the whole notion. The people using the estimates are making decisions based on those guesses. It also happens to be the people making the decisions are the ones in charge of the direction of the organization. Seems very risky, careless, dysfunctional, and irresponsible to use someone else’s guesses to make decisions.

Scrum is a message circulating around the globe without the proper wisdom or advice to put it into its proper context. Many implementations of Scrum are full of misinterpreted practices and processes.

“Everything we do in Agile is inductive logic and thereby empirical. Scrum, SAFe, RUP, Waterfall, etc. all inevitably use deductive logic and are thereby deterministic. If you believe that determinism is successful then you haven’t been paying attention over the last 50 years.” –Kevin Meadows

People often interpret pair and mob programming as waste since it is more than one person working on a single story/issue/item at the same time. This to me shows a lack of effective communication about pairing and mobbing. Is it the creators/authors (senders) fault? Perhaps. Perhaps the message being sent via the written word was not properly communicated by the sender. Is it the receivers fault? Perhaps. Perhaps the receivers world view and bias changes the intended purpose and meaning.

I mentioned reading Mob Programming by Woody Zuill and Kevin Meadows. And I can’t recommend it enough. But I have had many conversations with people that have seen Woody speak or who have read the book and are just going through the motions. They are using the book as if it is an instruction manual on “the right way” to mob program. If you have taken this approach after reading Mob Programming, I suggest you go back and read it again a little slower and avoid the implementation thoughts and urges you have.

That being said, the receivers interpretation or rather misinterpretation is not always a bad thing. Some great things have come from variations of interpretation of some of the things mentioned above. However, in my experience, it’s usually not so great things that come from contextually lacking interpretations.

“The single biggest problem with communication is the illusion it has taken place.” — Bernard Shaw

While face-to-face communication is always better, it is still not able to escape communication failures. I can recall growing up, getting a basic set of instructions from my father to take out the trash or mow the lawn. If I took the trash out of the house and put it outside the front door, did I take out the trash? Yes. Was it what he intended for me to do? No. Take out the trash meant, take the trash out of the house and put it in the trash can. If I mowed the lawn and stopped, did I mow the lawn? Yes. But I didn’t weedwack or clean up the clippings? Did I service the lawnmower to make sure it was ready for use the next time? Which by the way was what was expected and the intent of the mow the lawn request.

Were these faults of the sender or receiver? Does it matter who is at fault for the failed communication? Or is it more important to recognize the intended outcome of the communication failed, and to try to find ways to turn up the good in our communication?

Another example from growing up that gets to a possible solution. One of the many jobs I had in my teens was working in landscaping. We would build fish ponds and waterfalls for people as well as all of the usual flower bed type of work. My parents wanted a fish pond and asked me to do it.

We sat down and drew out what it might look like. Where it would be located in the backyard. How big the pond should be. If a waterfall, how big would the waterfall be. In what shape would it be in. Which kind of stone(s) to build the waterfall. Did we want one of those mushroom water filters for the center of the pond. What kind of fish and how many. We used that drawing and conversation to establish a shared understanding. A vision of the end state.

While I built the pond, my parents would inevitably say, “Now that I’ve seen it…”

What was actually happening here? I was building in collaboration with my customer. They would see how the build was progressing and they could make decisions based on real information. They could STEER!! Thank you Woody for that word in this context.

“Now that I’ve seen it…” is nothing more than steering. People are taking the most accurate real time information about what is being created and steering to a better outcome.

“If we can’t easily steer continuously we will fail.” –Woody Zuill