The biggest challenge for Agile is no longer establishing SCRUM teams or creating working software - the challenge in today’s fast-moving economy is releasing software that will move customers to buy and move the needle for business. In Agile, we practice Software Craftsmanship, but now the new imperative must be Product Craftsmanship. Here’s why:
To quote the first principle of the Agile Manifesto: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” If we deliver early and continuously, do we know that we are also delivering value? I ask myself these questions: Why doesn’t SCRUM, Kanban, or Scaled Frameworks result in market success? Why are enterprises with high-performing Agile teams still falling behind the competition?
Should we be satisfied with “better ways to create software” as an end goal, or is now the time to aim for something more meaningful?
As the community of “guiding Agilists,” we are becoming the root cause of brand erosion and market disruption for our clients. We continue to “help” our clients iteratively release software that no one will buy, no one will use, and may ultimately cost our clients their share of the Digital Economy. Should we be satisfied with “better ways to create software” as an end goal, or is it now time to aim for something more meaningful? We could be delivering a competitive edge, enabling enterprise success, and yes, even creating higher stock prices for our clients.
Those of us who have spent years working on Transformation know that success depends on more than the software development organization, yet I have heard many seasoned colleagues dismiss success with users or the market as a “Business problem.” We may have a product owner, but we are light on helping their leadership truly understand Agile or how to create a backlog. This attitude leaves product owners and product management teams alone to struggle with prioritizing and what valuable and usable means.
With only rare exceptions, technology teams still claim success and move on to the next big thing.
These business partners and stakeholders are also the folks left to live with the product (and customer feedback) released by the “high-performance team." With only rare exceptions, technology teams still claim success and move on to the next big thing. This trend makes Agile Transformation and even Agile adoption spotty, with stalls and resets rampant. We focus on Software Craftsmanship, when this problem can only be solved with Product Craftsmanship.
From the beginning, the Agile Manifesto valued minimizing waste through minimizing documentation while encouraging collaboration and communications. Lean adds more language around minimizing waste. However Agile and Lean do not merely suggest minimizing waste in all of its forms, they also encourage understanding of customers and economics. For example: What is the cost of delay for implementing one Feature before another?
Some of the tools of Product Craftsmanship are already seeing success in Agile. Those who have spent any time with the Scaled Agile Framework or read Don Reinertsen’s book The Principles of Product Development Flow can see elements of planning and prioritization based on value. Reinertsen suggests “taking the economic view,” and Leffingwell prioritizes based on “weighted shortest job first.” But sadly, Agilists in these scenarios usually end up coaching a planning processes and assume that software craftsmanship and product craftsmanship already exist in the organization.
We must start coaching and teaching both Software Craftsmanship and Product Craftsmanship, otherwise we will lead clients to disruption.
So, who are the Product Craftsmen? In the Lean Start-up community, Eric Reis and colleagues such as Steve Blank, Brant Cooper, Alex Osterwalder, and Yves Pigner seem to have Product Craftsmanship well in hand. According to that community, you need to test your assumptions (or Hypotheses) in real time while developing an idea. You then pivot as needed, change your business model as you learn, and constantly “get out of the building” to gather data and validate what will truly be successful in the market.
A perfect example of this is a scene in the movie The Social Network in which Mark Zuckerberg is racking his brain, knowing the product didn’t yet have what it would take to be a success. A classmate named Dustin runs over:
DUSTIN: “There’s a girl in your art history class. Her name is Stephanie Attis. Do you happen to know if she has a boyfriend?”
MARK: “Why am I being interrupted?”
DUSTIN: “Have you ever seen her with anyone? And if not, do you happen to know if she’s looking to go out with anyone?”
MARK: “Dustin. People don’t walk around with a sign on them that says—“
Mark stops and realizes what his product needs to be successful: a relationship status. The rest is history. Mark was successful because he left his dorm room, went out into the world, listened to his users, and immediately changed the product based on what he learned. Turns out Facebook was somewhat successful.
It’s very likely that if your business isn’t doing what Mr. Zuckerberg did as a way of working, you might as well burn your investment money - you won’t build the right product. The Lean Start-up approach works, and some smart enterprises are already adopting as many aspects of this system as possible. Lean Startup is a proven way to assure a valuable Product Model and it puts you on the path to Product Craftsmanship.
In the meantime, what is the Agile Community offering? We say the product owner owns the backlog and for the most part, that’s the full extent of our participation in Product Craftsmanship. Sometimes we might say something that sounds impressive, but is merely time-based: “You need to break epics into features and then break those down into stories that will fit into an iteration”. Where is the value? Where is the guidance to assure that value is being created based on solid, client focused empirical data?
We must start coaching and teaching both Software Craftsmanship and Product Craftsmanship - otherwise we will lead our clients to disruption. Or perhaps Agile simply becomes irrelevant.