My daughter is in the phase where she’s always asking me “why?”, so she asks me, “Why do you go to work?” …and I hate how a toddler has given me so much pause… because I don’t like my answer.
Here’s a window into an internal struggle:
Do you work for a company with an inspiring vision? Why the heck not? And why do you choose to spend your days contributing to a group that’s not improving humanity?
And now, here’s my struggle as I iterate on my Agility:
Why continue to focus on how things are being built & done when what we are building & doing is not improving humanity?
What do I tell my 2-year-old daughter?
Agile focuses on process, having it be light-weight and continuously improving, usually starting with Scrum (roles & events & artifacts derived from a survey of successful projects from successful companies) or Kanban/Lean (principles derived from the Toyota Production System).
Granted, the first Principle behind the Agile Manifesto mentions doing some form of good for a human:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
But how do you know? Well, the Agile Manifesto itself provides the value of:
Customer collaboration over contract negotiation
But this stresses a working relationship preference, and since customers don’t always know what they need, who’s to say this will help the species?
That’s right. This is what I care about. And this is what I think we all should care about. Something this high-level. I believe a progressive product mindset entails bearing some responsibility – bettering humanity – versus unjudgementally placating users.
Scrum says it’s up to the Product Owner to be “maximizing the value of the product resulting from work of the Development Team”, partially via “Ordering the items in the Product Backlog to best achieve goals and missions”.
But what if the goals and missions are
Agile is good at operationalizing a machine, but if the machine isn’t doing good, then what good is focusing on Agile?
This is refreshingly addressed in one of the four principles of Modern Agile:
Make People Awesome
Great, yet I’m still looking for something that will better take the “improving humanity” banner.
That’s where Bruce McCarthy, and his movement towards a Product Culture Manifesto, has the following principles:
1. Customer-driven mission
2. Outcome over output or process
3. Leadership over management
4. Team over function
5. Technology is a core asset
In contributing to the Product Culture manifesto/movement, and fueled by how it’s not enough to just satisfy the customer, but that we also need to inspiringly better humanity, I have crafted a model that I’m happy to evolve, and currently has me sleeping more easily, not because I have an answer for my daughter, but because I now have a tool to help me think about that answer.
The following is my take on Product Culture, which I shared with Bruce – like I said: a high bar – and now one I share with you all. In my mind, a Product Culture of inspiringly bettering humanity is the highest good that Agile can serve.
After sitting with the current five principles, which included comparing them to both the Agile Manifesto and ModernAgile.org, and wrestling with how they all tied together, I gave in to my need for a system level understanding of Product Culture by diagramming components of what I think it is, from which I derive a new five principles.
PC1. Inspire with a vision (start with why we are driven)
PC2. Empathize as a human (continuous curiosity for the people we serve)
PC3. Focus on the problems (continuously analyze how we can be most impactful)
PC4. Act to learn or change (continuously experiment)
PC5. Seek and embrace feedback (humbly inform how we focus and act)
It starts with the notion that, during the day, we are being paid to make things and do things that improve people‘s lives, and I see that as a diagram where the Present State of humanity (PC2) is connected to the Future State of humanity (PC1).
As we go about improving people’s lives, we’re doing one of two things: understanding the present, or moving towards the future. This requires focusing on the problems (PC3) and then doing something to either understand the present (PC4 / learn) or move towards the future (PC4 / change). The result is fed back so we figure out what to do next (PC5).
To my engineering and agile mind, with a limited understanding but growing appreciation for a progressive product mindset, this is how I view product-related activities to be most beneficial.
To me, this also represents the essence of a successful product mindset, where other aspects are either auxiliary or derivative.
Regarding the content of PC1-5, I acknowledge that there is some overlap with the current 5 principles, the agile manifesto, and modern agile; however, this new set of principles feels organized, self-contained, as well as more focused on product-related concerns.
Regarding characteristics of PC1-5, I have framed them to be short, have about the same number of syllables (minus the things in parentheses), and start with a verb, since my thoughts on a manifesto include that it should be a call to action.