A leadership groups experience
Over the years many have tried to find the right words for when working with organizations and teams trying to work “agile”. Basic statements like:
- “Slow down and deliver value.”
- “It doesn’t matter how fast you are shipping stuff people don’t want or use.”
- “More faster is not a product strategy.”
I recently had the good fortune of meeting Jeff Patton and having some great conversations around Product Thinking and Product Leadership. If you can, I would advise taking his course on Passionate Product Leadership.
There was a conversation among leadership in one organization on this very topic and how the business and I.T. are working together. As with most organizations where I.T. builds software tools for other members of the organization, they are working in the “service-provider” or “IT-As-A-Service” model.
- The business comes up with “requirements”. – Oh how I dislike that word…
- I.T. tries to understand the “requirements”.
- I.T. provides an estimate of how long it will take.
- Negotiation occurs. It is usually a discussion that ends with I.T. accepting an unrealistic deadline to deliver every “requirement”.
- The business makes the official order for what they want.
- I.T. delivers the software.
- I.T. moves on to the next set of “requirements”.
Statements are made in these organizations such as: “This is the way we’ve always done it.” or “It is part of my job as a developer, I build what they tell me too.” Even the following exchange between two people, Joe is an Audit Manager and Mark is a Developer working on a new system for the Auditors:
Joe: “What you built doesn’t work.”
Mark: “I built what your requirements said.”
Joe: “Well now that I see it, I forgot something.”
Mark: “That’s not my fault.”
Obviously, this is not the most healthy relationship.
Leadership Conversation
The conversation with leadership was around the struggles both the business and the teams working this way were experiencing.
- Features not being accepted.
- No visual into if features are being used.
- Slipping due dates and lack of quality since there was so much to do in so little time.
- Business complaining about how I.T. doesn’t give them what they need.
- I.T. complaining about how the business makes unrealistic demands or there is too much “scope creep.”
Each one of those is a solid topic in their own rights. But what landed this time was when this question was asked, “We don’t seem to focus on the Outcomes instead of the Outputs.” And there was silence. All those other basic statements would easily have been glossed over. People would immediately have some bureaucratic response along the lines of “Agile is about responding to our changing needs as a business.”
Instead this time, the response was “What do you mean?” or “Yes, how do we do that?”
This group chose a specific feature that was recently delivered. They looked at how long it took to deliver and if the Outcome was as expected. That is when they hit their first road block. Nobody knew what the Outcome or Impact of the feature should be. It was never a question. The business said “Give me this thing, exactly this way.” And that is exactly what that team did. Which is exactly how all of the teams are currently structured and working.
Just to avoid the possibility that it was a bad example, they pulled another feature at random to find the same scenario played out.
After this revelation set in, they set out to answer the following questions.
- What problem was this feature solving?
- Did this feature solve the problem?
- Was this feature being used?
- Does the user like using the feature?
- Does the feature need to be improved?
Now this is great as a post mortem exercise. And guess what, the answers where as you expected.
- What problem was this feature solving? For the sake of sanity and space, we found it.
- Did this feature solve the problem? Kind of.
- Was this feature being used? Sometimes, mostly because you had too at some point.
- Does the user like using the feature? No.
- Does the feature need to be improved? Absolutely.
Knowing all of this, where was the improvements to the feature on the teams backlog? You guessed it, didn’t exist. None of the user’s were taking the time to make requests for changes and nobody was following up to see if that feature was working out. No data was being collected from the system on usage either.
As you can imagine, this group started combing through the system of released work over the past few months and found countless occurrences of this same scenario. The system is what I like to refer to as “Frankenware”. It is a bunch of little pieces of different things just thrown together.
This landed with leadership, and they were on board for working in a different way. But that change would not just require process and practices changes, it would require cultural changes as well.
Chris Pipito 