What does the 4th Agile Principle (Business and Development Work Together) look like in Action?

Many want to go Agile or claim to be Agile. The question is, are you and will you align with the Agile values and principles? In this article, I expand on the fourth principle to better understand what it means and attempt to identify what evidence looks like to determine if a culture change may be occurring. What is this principle?  

Business people and developers must work together daily throughout the project. Agile attempts to bring an understanding of business value to the development team and the technical choices and challenges to the business side. To do this, it attempts to integrate business and development as one team. In traditional approaches, there is often little interaction between the business (e.g., product management, sales, and marketing) and development (aka, cross-functional technical team). On the business side, this may be the Product Manager or Business Owner. Scrum introduces the Product Owner (PO) role and XP introduces the Customer role as the bridge between the customer and the development team. These roles allow for a closer embodiment of the business and development team spirit and avoid fiefdoms and throwing work “over the wall” from one group to another with little interaction. 

The intent is to make a sincere effort to build a collaborative and amicable yet productive relationship between business and development. Development benefits from a better understanding of what the customer finds valuable. The business side benefits because development will ask for details that the business may not have thought about. In both cases, the result is a product that more closely aligns with what the customer finds valuable. What actions and evidence exhibit business people and developers working together?

• An established and productive relationship between business/customers and development
• A dedicated business owner who works continuously with the development team. 
• Development comprises a cross-functional team with developers, testers, technical writers, designers, and so on. 
• The business owner with the development team work together during iterative planning to build a mutual understanding of the requirements of what to build. 
• The development team demos the working product to the business owner and customers to gain feedback to better align with customer value. 
• The development team can reach out to the business owner whenever needed throughout the project lifecycle.   

It is up to you to determine what supporting evidence will highlight that continuous integration, build, test, and frequent delivery is occurring. It is worth experimenting with this as it will help you better understand and embrace the Agile principles. The ultimate question is, do you believe that business and development should work continuously together as a team?

-------------------------------------------------------------------------------------------------

To learn more about what the Agile Principles look like in Action, consider reading:

• 1st Agile Principle (Satisfying Customer with Valuable Software) at: https://cmforagile.blogspot.com/2023/09/many-want-to-go-agile-or-claim-to-be.html
• 2nd Agile Principle (Welcome Change to Requirements) at: https://cmforagile.blogspot.com/2024/01/do-you-have-evidence-to-support-2nd.html
• 3rd Agile Principle (Frequent Delivery) at: https://cmforagile.blogspot.com/2024/02/what-does-3rd-agile-principle-frequent.html

Who really is the Customer?

As straightforward as this question may seem, it engenders a wide variety of answers that tend to be murky. The real answer is clear. A customer is someone who has a choice on what to buy, external to the company, and a choice of where to buy it.  As it relates to your company, a customer pays you with money to help you stay in business by purchasing your products.  For these simple factors, engaging the customer is of utmost importance.

Most companies like to say that "customer is king" and some indeed are.  But if you ask those in a company when was the last time they actually talked to customers, many say rarely or never. As bizarre as it may sound, there are challenges that companies have in relation to engaging with customers.

The first challenge is that the term “Customer” is being applied to a number of people “internal” to the company who are not really Customers. This means they don’t pay and bring revenue to the company. Instead, they are really internal stakeholders or partners. When you incorrectly title someone a customer when they are not, then when you apply Agile, it will not really be customer value-driven as you are not using actual customer feedback to drive toward customer value.

The second challenge is that some companies do not really engage their customers to get their feedback to understand what they find valuable.  This is often for two reasons. The first is that there is pretend or arrogant certainty from those in the company on what they think is customer value so they don’t really think they need to engage with customers. The second is that the company optimizes for sticking with the plan over adapting to customer feedback. In both cases, this prevents the opportunity of gaining valuable customer feedback. 

The key to engaging customers is to gain their valuable customer input and feedback.  The input and feedback should be the basis for driving a majority of your decisions and setting the direction of the product. As you look to build a customer value-driven engine within your enterprise, the customer or more specifically, customer feedback, is the “driver” that steers the engine of customer value.  The more you incorporate the customer at the center of your company, the more likely you will have satisfied customer and greater business success.

Learn if you incorporate customer feedback with the Empty Customer Chairs technique at: 

http://cmforagile.blogspot.com/2016/03/empty-customer-chairs-illustrating.html

-->

The Power of Agile is in your Customers and Employees

I’m Agile, you’re Agile, everyone is Agile.  Or folks think they are.  But are they really? If Agile is only a process to you, Agile will fail. If Agile is pretending certainty without validating with customers, then Agile will fail. If Agile is commanded from above with little ownership from the team, Agile will fail.  More importantly, not only Agile will fail, so will your business.  Agile is a move to a lean culture focusing on customers and what they find as value and focusing on employees who are the engine that can create that value.  Agile is effectively about creating a thriving business. 

I believe there are the two primary success factors in creating a thriving business: a culture where customers matter and employees matter. I’m not talking about the lip service that is prevalent today. In some cases, we see quite the opposite, where employees are disenfranchised and customers are rarely engaged. Instead, the goal is to have a culture and practices in place that truly gain the benefits of engaging with customers and employees. Through the customer and employee, a company draws their power within an agile culture and, I contend, within any thriving company.

When you have a riveting focus on the customer and you believe that an engaged customer matters, then you have the basis for a relationship where you can truly understand what the customer wants. When you have a sharp focus on employees and provide them the space to make decisions and own their work, then you will begin to understand the value an engaged employee base can provide.

If the values are sincerely translated to organizational objectives and agile approaches are applied, then it can act as a differentiator between the success of your organization compared to the success of other organizations. Of course, every company likes to say that employees and customers matter, but are their objectives and actions really aligned with these values?

Upon closer inspection, the values should translate into objectives focusing on customer engagement and employee engagement.

• Customer engagement focuses on establishing meaningful and honest customer relationships with the goal of initiating continuous customer feedback to truly identify what is valuable to the customer. This includes establishing all of the activities involved in a Customer Feedback Vision.
• Employee engagement focuses on empowering employees so they can self-organize into teams and can own and be a part of the decision-making process at their own level.  When employees have ownership, they have more passion in their work.  When they have more passion, they give 110%. 

Then we add the “secret ingredient” of applying a continuous and adaptive approach (a.k.a. agile culture, processes, methods, practices, and techniques). If done properly with the ability to adapt, this can lead to an increase in customer sales and an increase in team productivity. This finally leads to your incentive, which is an increase in company profits.  

Now is time to take a moment.  Are employees disenfranchised or fully engaged?  Are customers rarely engaged or is their feedback continuously engaged?  Is Agile just a trend that others should do or are you serious about Agile and the culture shift it requires?  Keep in mind, the combination of customer and employee engagement within an Agile context isn’t just a good idea, it is great for business.  

PS - to read more about the importance of customers and employees, consider reading Chapter 3 of the book entitled Being Agile.  

There is no Success or Fail, only Learn

I have been in discussions both in-person and on twitter with colleagues on whether we should use the word “fail” or “learn”.  This was in context to projects (aka, releases, increments).  Did they failed or did we instead learn.  I also realized that the term “fail” is somewhat subjective (e.g., did the whole project fail or just parts of it?).  The overwhelming agreement was that “what did we learn” was a better way to discuss the findings or results. This lends itself to a shift in mindset, to a continuous learning environment that recognizes that there is value even in the negative feedback.   We can learn from that feedback and adapt for better results in the future. 

Then it occurred to me, the term “success” was also a bit subjective.  I recall reading a Standish Group Study where those projects that were “deemed” successful, 45% of the features were never used.  Another 19% was rarely used.  This meant that projects deemed successful built 64% never or rarely used features.  That seems to be a very loose definition of what “success” looks like.  In addition, how many projects are deemed successful because it met the scheduled deliver date yet few customers upgraded to it or bought it?  Is there a benefit to use the term “learn” in place of success?

While it may sound feel like the terms success or fail are the way to traditionally judge a project, release, product, or service, we lose sight of the most important result of the work, the feedback and what we learned from that feedback.   This learning helps us adapt to achieve better results.  If you are working in an Agile context where there are short increments of work, there is the benefit of continuous learning where you can continuously adapt for better business results.

I would suggest in the modern lexicon of work, when a project, release, or increment of work is done, it is much more important to ask what was learned instead of classifying it as a success or failure.  This strengthens the mindset within the organization that there is a value in feedback and the most important thing is what did we learn.  It also emphasizes a discovery mindset where what we think a customer wants is really a hypothesis that must be explored.  It is in the learning that can help us lead to better business results in the future.  So next time people talk about a project as a success or failure, instead turn the discussion around and ask “What did we learn”?  

Startupbucks (aka Starbucks) the OaaS Innovation Incubator

As I was momentarily pausing from working on a presentation, I leaned back and noticed that there was quite a bit of “business” occurring in my local Starbucks.  There were a lot of enthusiastic conversations with a collection of open laptops, notebooks, tablets, and more being used to share, illustrate, and note ideas.  This wasn't the first time I’d seen this same level of engagement in a Starbucks. 

Then something occurred to me.  I was witnessing an incubator of business, non-profit, and personal ideas being generated and matured.  Of course some people are there for just a coffee and a chair to relax.  Others are there for a quick pick-me-up for the day or remainder of the day.  Alternatively, it was clear that Starbucks was this place where business was happening, where new ideas were being generated, where collaboration was happening, and where progress was being made.  It was an incubator of innovation! 

That’s where it occurred to me, Starbucks was part coffee shop and part office-as-a-service (OaaS) incubator.  I therefore have redubbed Starbucks to Startupbucks!  The first part of the name (Startup) is a place where new ideas come to life and blossom surrounded by the aroma of coffee beans.  The second part of the name (bucks) is coincidentally where hopes for financial reward is part of the innovation dream.   I wonder how much business has been conducted in Startupbucks and much money this translates into?   Next time you are in Starbucks, take a look around.  Are you seeing the same thing that I am?  Finally, thank you Starbucks and the many coffee shops like you for providing us this OaaS that makes a great incubator of ideas and haven for progress!