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

The Importance of Language in a move to an Agile Culture (with Polling Results)

In my experience in helping teams transform toward an Agile culture, moving away from the traditional terminology and adapting Agile terminology is very beneficial.  At the same time, I have sensed reluctance in organizations in removing from their traditional language.  I believe the language you use matters a great deal if you are attempting to achieve a certain culture.  A prime example is moving from the language of certainty in a more big-upfront Waterfall culture to discovery and hypothesis driven language in an incremental Agile culture.

If you are trying to change culture, the change in language highlights that something has changed and provides folks with a learning opportunity assuming that there is true meaning behind the language and a commitment to change. It makes everyone pay more attention. If you think about it, when you travel from one culture to another, the language does indeed change.  Using the proper language helps you inform and communicate needs more effectively while a common language provides a bond within our community.

Maybe the key is to use language that is most efficient and effective for the culture you want to get to. If you want to change your culture, you need to ensure that the language is not tripping you up and dragging along its baggage of prior meaning.  When you move from a big-upfront Waterfall to an incremental Agile culture, using the same waterfall language will trip you up.

Why? Because people in the organization still think the definition of the term is stemming from the 'old' culture. Attempting to change culture is hard enough and when you have language from the old culture still around, you can be sure that those people within the org are still interpreting the language using the old world context. This can impact your success to advance your new culture. 

With all of that being said, this is the opinion of one person.  So what of the opinions’ of others?  With that in mind, I embarked on a poll via LinkedIn to gauge other’s thoughts on how important is it to use Agile terminology to get to an Agile culture.  I present you with the following results:

Within a period of a month, there were 83 votes cast along with 26 comments.  The poll results revealed that 65% percent (or close to two-thirds) of the participants felt the use of Agile terminology was either ‘Very Important’ or ‘Important’ for an Agile culture.  Another 12% felt it were neutral.  The remaining 23% felt that the use of Agile terminology was of ‘Little Importance’ or ‘Not important at all’.

In order to more fully understand other opinions, I have included a paraphrasing of some of the comments.  They include: there is a need for specialized vocabulary; there are fundamental differences amongst various practices and methods so terminology should be considered; the terminology contributes to language precision; and the words used should work for the culture.  You can see one of the threads within the “Agile” Linkedin group for specific comments from others.

Some took my examples literally.  I didn’t really mean to imply that the term ‘sprint’ and ‘phase’ are the same, but I have seen teams use those terms interchangeably.  So I do agree that one term is not necessarily better than another but that you should ensure the language you use does not get in the way of learning and advancing within your culture.   Also, I’m not clear that there needs to be a standard “Agile” terminology across the industry.  However, with that said, if you are applying Scrum, you should use Scrum terminology (and the same for XP, Kanban, etc). There is a value of having a common Agile terminology within an organization so that there can be a more effective platform for Agile related discussion across teams.  

Also a few people mentioned that the meaning is more important than terminology.  I do favor this line of thinking because there should be an effective meaning behind all terminology used.  Terminology without meaning is babble.  So yes, it is important, dare I say critical to have a well understood and clear meaning behind all the terminology used in order to gain an effective Agile culture. 

Ultimately if you are truly trying to initiate a culture change, then the language should reflect the change you are looking to make.   In this case, if want to establish an Agile culture, utilize the terminology that provides an appropriate and clear meaning which drags little or no baggage.  This will help you get to the Agile culture you may be seeking.  Cheers!

Note: another article that discusses Agile terminology focusing on the terms 'size' vs 'estimate' may be found at: http://cmforagile.blogspot.com/2012/10/size-matters-using-size-instead-of.html

Book released in the US - Adapting Configuration Management for Agile Teams

Exciting news! My book “Adapting Configuration Management for Agile Teams” which is on the world market is available in paperback and now as a Kindle ebook!  It is the first book of its kind that combines discussions on both CM and Agile. Agile is the facilitator of change while CM is the enabler of change. When done properly, CM provides the right level of control for Agile projects to maintain and increase its high level of velocity. CM for Agile can be a very powerful combination when done effectively.

How can it help you? Aimed at all levels of professionals in the Agile, Configuration Management (CM), Project Management, Product Management, and Development fields, this book provides very tangible support for Agile teams. It focuses on how CM with its practices and infrastructure can be adapted and managed in order to directly benefit Agile projects

What are some unique features of this book that can help you?

 • Provides both an Agile Primer and a CM Primer. For those experienced with CM, it provides a solid overview on Agile(or visa-versa on CM) so you can come up to speed. It can be great for someone who wants to learn both. It’s almost like a two-for-the-price-of-one book!

 • Provides insightful and concrete guidance on adapting CM for Agile methods while maintaining CM principles and allowing minimal structure needed for Agile projects to continue to run fast. Adapting CM for Agile doesn't mean throwing out the CM principles of identification, control, audit and report. Instead it means that CM should be adapted to allow the lean nature of Agile. The question is how do we do this? Inside, learn how to adapt:

o Continuous Integration and Build applying notions of bit-size tasks, right-sizing branches, minimizing merging, emphasizing continuous build, and testing with teeth.
o CM Planning (aka CM Vision) moving away from big-effort-up-front (BEUF) to a more evolutionary approach, applying an iteration 0 to get started, adapting CM roles and responsibilities, and using wikis and other CM formats.
o CM to support more effective Refactoring, Pair Programming, and Test Driven Development (TDD), Traceability, Baselines, Problem Management, CM Audit, and CM Reporting and lean metrics.
o CM support for Distributed Development for Agile teams when co-location is not an option by performing a distributed analysis and considering code access solutions, and supporting a Cloud infrastructure option.
o CM infrastructure for Agile thru implementing CM Envisioning for a brand new product following Agile methods or thru CM Refactoring to adapt CM for an existing product line moving to Agile methods.

• Will help you understand how the more modern CM features help with implementing Agile in an effective manner and that CM tools are a strategic Agile partner.
• Will help you understand how to more effectively support Agile when your organization, product, or project must align with standards and frameworks.

Again the book is called “Adapting Configuration Management for Agile Teams” (ISBN-10: 0470746637). This book is available on both the Agile and Wiley websites. Also, if you want the original CM book which people love as a great CM reference book, feel free to consider, “Software Configuration Management Implementation Roadmap” (ISBN-10: 0470862645).

Have a great day!