It's Time for Product Craftsmanship

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.

Digital Transformation Changes the Game

I was working with a large company that had started piloting a Digital Delivery model in one business line.  They had co-located the business, technology, and support functions.  The pilot was a success – the team had delivered improved product line performance in less than 6 months.  They had even trained the call center and created a marketing campaign.  However, the rest company continues to use old PMO model of percent allocating resources to projects.  They were delivering more projects than ever…but with increasing client attrition.   

The COO had called a meeting with his direct reports to discuss expanding the teaming model, but had gotten push back from his leadership team.  They said they communicated the urgency of client losses to their organizations, and that pulling people away from active projects would cause disruption and delays.  

Next he called a meeting with me and here's an except:

COO: I don't get it.  How am I going to convince these guys that we need to rapidly expand the team model so we can release full solutions out to our clients?  They all know we have a big problem with client attrition.  They tell me they are communicating urgency to their people, but the first pilot team released a solution that stopped client erosion – and they did it 10 months early. 

Me: Think of it like this: Most of your employees are experts and excellent at the jobs they have today.  They are like professional-level bowlers who are awesome at bowling strikes.  All day, they get a ball, they bowl strikes.  The more strikes, the more your leadership is rewarding them.  Leaders and management communicate urgency, everyone says “You got it, Boss!” and start to bowl strikes faster. Now you are saying "We are all going to start playing BASKETBALL!"

COO: But this is what I want.  I want teams that can deliver on a common goal, working together - getting solutions out to market for our business and for our clients.  We can't have individuals bowling strikes with no understanding of what is happening on the 'other lanes.'

Me:  Yes!  Here is what is happening on the ground, though.  We say: "Today, we are going to start learning how to play BASKETBALL" and we hear: "GREAT... but can I still use a bowling ball?  See, I already know how to use a bowling ball, and it’s still a ball.  I’ll even call it a basketball.” We explain that people get hurt when they try to catch a pass if you use a bowling ball, and the next question is “Well, can I at least stay in this alley, it has hard wood floors? It’s narrow, and I can put up bumpers if I want to –”.  This conversation slows down any move to model we used with the pilot team.

COO:  And now, by communicating urgency to their people, my leadership team has basically told everyone “Bowl Faster!”

This is a common scenario.  Though every organization may have a different structure or business model when they start, Digital Transformation must fundamentally change the game you are playing.  Messages that your leadership sends through the hierarchy (or rumor mill) can make or break employee willingness change the way they work.  

How many of your company goals can be met if your Leaders communicate the same rules they have for over a decade, but with more urgency?   The answer is NONE.  Your Leadership’s understanding of this fundamental concept, as well as the communication of it to the rest organization is imperative. 

…and sports analogy usually helps. :)