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

What does the 2nd Agile Principle (Welcome Change to Requirements) look like in Action?

Many want to go Agile or claim to be Agile. The question is, are you and will you really align with the Agile values and principles?  To better understand what this means, I dissected the Principles to better discover the intentions behind them and what behaviors they entail. In this article, I expand on the second Principle to better understand what it means and to attempt to model how to marshal supporting evidence that a culture change may be occurring.  

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage is the second Agile principle. From an Agile perspective, you embrace change to increase the chances of delivering value to the customer. You embrace change because you understand that change is necessary as customer needs, market conditions, and general demand change over time. 

Welcoming change implies several qualities. The first is that there is a positive attitude toward change from the team and management. The second is that while change ideas are admitted, they are methodically prioritized based on customer value along with existing requirements. The third is that there is a process that allows prioritized changes to flow without obstruction.

What actions may exhibit “welcoming change to requirements”? Some evidence includes:  

• The PO continually engages with the customer to identify new requirements or changes to existing requirements. 
• A methodical review of the change idea occurs to determine the priority amongst the existing requirements.
• No person or process restricts incoming change ideas. 
• The backlog is continually refined and reprioritized. 
• Increment Planning and/or Sprint Planning is applied to introduce the newly prioritized requirements. 
• Continuous customer engagement via customer visits and sprint reviews are applied. 

It is up to you to determine what supporting evidence will highlight that a culture change is occurring. It is worth experimenting with this as it will help you better understand and embrace the Agile principles. The ultimate question, if you really believe in this principle is, do you welcome change?

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

To learn about what evidence might look like to support the 1st Agile Principle (aka, Satisfying Customer with Valuable Software), consider reading: https://cmforagile.blogspot.com/2023/09/many-want-to-go-agile-or-claim-to-be.html

What does the 1st Agile Principle (Satisfying Customer with Valuable Software) look like in Action?

Many want to go Agile or claim to be Agile. The question is, are you and will you really align with the Agile values and principles?  To better understand what this means, I dissected the Principles to better discover the intentions behind them and what behaviors they entail. In this article, I expand on the first Principle and attempt to model how to marshal supporting evidence that a culture change may be occurring.  

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software is the first Agile principle.  Satisfying the customer means delivering valuable software in a timely manner (that is, in the market window) for a reasonable cost. Continually striving to meet elusive customer value is important. Ultimately, the key measure of value for customers is an increase in sales and the continued loyalty of existing customers. 

How do you know that you are moving in the right direction of building value? It starts with understanding your customers: who they are and what motivates them. Their profiles include such information as their challenges, their vision for your product, and their buying trends. 

Delivering value continues with an effective sprint review process where the customer gains an opportunity to review and provide feedback on working software. If customers can sense that their input is valued during the demos, their satisfaction can increase. This is particularly true if the customers see that their feedback from the last demo has been incorporated in the working software of the current version. 

In addition, it is beneficial to use the Business Owner/Product Owner (PO) as the delegated voice of the customer to solicit acceptance criteria on what the customer would expect when they see a particular requirement or feature in action. You may also conduct periodic customer surveys to gauge their level of satisfaction with the product or solution. 

What actions exhibit “satisfying customer with valuable software”? 

• The PO works to understand customer value, constantly prioritizes and refines the backlog, and discusses customer needs with the team. 
• The PO creates customer profiles to recognize motivations. 
• The backlog is your single source of requirements (aka, value). 
• The Customer vision reflects how you wish to engage your customers. 
• Business Strategy focuses on delighting the customer. 
• Customers are an integral part of Reviews to provide feedback and validate value. 
• Acceptance criteria are been captured and met for each user story. 
• Customer satisfaction surveys are periodically conducted. 
• Customer revenue metrics are captured and reviewed.  

It is up to you to determine what supporting evidence will highlight that a culture change is occurring. It is worth experimenting with as it will help you better understand and embrace the Agile principles. The final question, if you really believe in this principle, do you believe in continuous customer engagement, adapting requirements, and validation as a means of building valuable software to satisfy the customer? 

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

Learn more about what other Agile Principles look like in action:

• 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
• 4th Agile Principle (Business and Development Work Together) at: https://cmforagile.blogspot.com/2024/03/what-does-4th-agile-principles-business.html
• 5th Agile Principle (Motivated Individuals who are trusted) at: https://cmforagile.blogspot.com/2024/04/what-does-5th-agile-principle-motivated.html

Culture of Challenging Assumptions

 When you calculate the value of an idea, epic, or feature (e.g., revenue, cost of delay, etc.), many assumptions are made. As part of transforming toward an Agile culture, it is important to apply a discovery mindset that includes positively challenging assumptions so that you can better understand the value of an idea or adapt the value accordingly for the greater success of your company.

For example, a new idea is recorded that states a value of $1,000,000. The first step in challenging assumptions is using open-ended questions.  Open-ended questions allow you to ask questions in a non-confrontational way. Examples of open-ended questions include: What led you to that conclusion?; What do you think the level of uncertainty is?; What is your riskiest assumption?; and What information do you need to validate this?

The second step is to validate the answers. For example, if the revenue value of an idea is $1,000,000 and based on a conversation rate of 6% but the average conversion rate for products in the field is 4%, then the calculation of value should be adjusted lower accordingly. Alternatively, if the idea uses the same potential population of potential customers as the first product that entered the field, then it is less likely that the second product entering the field will have the same potential customer size. 

The third step is that you must challenges the assumptions of all ideas fairly and equally. By having reasoned conversations about those assumptions and ironing out the differences, you can get a consensus on the value so they can be fairly ranked. When the value is subjective, gut feel, those discussions can turn negative and the organization may end up putting their valuable employee effort onto lower value ideas.  Inversely, the more willing and the more objectively you challenge assumptions, the more likely you will put your employee effort to good use on high-value ideas and greater success for your company

Can your Desk become your Kanban Board? Yes, it Kanban!

Once upon a time, I found I had little space in the office to organize my work.  With the more recent office hoteling policies, while there is more flexible space, there is less of one’s own personal space.  I wanted a place where every morning I can quickly visualize my work for the day ahead. While there are online tools that I can use, I wanted something more tactile.  What I did have was a desktop surface.  I did have post-its, and sharpies.  I decided to experiment with Kanban on a physical desktop. 

As an Agile Coach, I work in iterations and increments much like I educate and coach teams and organizations.  It allows me to listen to what my customers want and prioritize the work based on value, much like a Product Owner should do. With this in mind, I used my simple tools to craft a kanban board on my desk.

Before I go any further, allow me to provide you with a brief description of what is a kanban board.  It is a work board that helps you visualize both the work and the flow of that work. It helps you optimize the flow of your work by understanding your WIP (work in progress) limit. In its physical form, it is usually shaped by a few state transitions as columns, the most basic include ‘To Do”, “Doing”, and “Done”. My work card (where I write the activity) was written in canonical form and I added when the task was written and then when I completed the work on the card, the “done” date so I could understand my flow.

I took the initial discovery activities that my client (aka., customer) and I agreed to, wrote them onto post-its with my sharpie, and added them to the kanban board in priority order based on both value and order dependency.  As I completed some of the discovery tasks, I added new tasks from my customers to the “To Do” column and reprioritized on a regular basis.  I experimented with keeping my WIP limit to about 3 activities in “Doing” at a time.

What I liked about this kanban experiment was that each morning when I got to my desk, I had my work right in front of me.  This immediately reminded me of my work for the day. It was very easy to maintain as it only took some post-its and markers to update the board. Every morning I checked the work that was in “Doing” so I knew what I had to get done for the day. I also enacted a quick reprioritization of the work so I knew what to pull from the “To Do” column when I had available WIP.  I managed to get a lot of work done this way. 

I’d say the experiment was a success.  What did I learn? That it is too easy to add more activities into “Doing” adding to WIP. This had the unfortunate result of slowing my throughput. What else did I learn?  That yes I kanban!

The Difference between Self-Management and Self-Organization

This is the second slice of the four-part series on Self-Management. The first article describes what is self-management. The third article focuses on how to apply self-management. The fourth article shares the challenges in moving toward self-management.  This second article discusses the difference between self-organization and self-management. 

Why write an article on the difference between self-organization and self-management?  The main reason is that many people conflate the two words and concepts when, in fact, they mean two very different things.

Within a self-organizing structure, teams own the 'how' to do the work, along with deciding 'who' does the work within the team.  You will often find the self-organizing concept applied to an Agile environment, where the Product owner owns the priority of the work (aka, the ‘what’) and the team owns the 'how' and 'who’. 

In a self-managed structure, employees own the ‘how’ and who, along with the 'what' to work on.  The ‘what’ means that employees prioritize the work activities.  In each cases, there is the mission level 'what' and 'why' for the organization defined by the leaders of the company that both must align with.  

In self-management, employees own much more than the work activities at hand.  They own the priority of the work, the overall planning, management of their own budget, and HR aspects like compensation and staffing.  This also includes the team deciding who is on the team or how the team is structured.  None of this occurs in self-organization teams.  It is just limited to the ‘how’ and ‘who’ owned by the team while the Product Owner (or Manager) defines the overall planning and priority of the work and the manager handles the HR aspects of the work.   

It is easier to apply self-organization to teams (compared to self-management) as the ‘who’ and ‘how’ are typically activities within the team boundary (working with just other team members).  Self-management activities extend beyond the team to areas like working with HR, finance, and more.    

For those interested in self-management, it is recommended to understand and attempt self-organization first.  If your business is ready for you to both own the ‘how’ to do the work and ‘who’ should do the work, then self-management may be considered.  If there is still resistance to these aspects of self-organization such as project management or managers continuing to decide who does what, then this hurdle must be resolved before attempting self-management.

--> To read the first article in this Self-Management series, see: What is Self-Management and is it good for Agile? 

The Forgotten Agile Role – the Customer

Many Agile implementations tend to focus on the roles inside an organization – the Scrum Master, Product Owner, Business Owner, Agile Team, Development Team, etc.  These are certainly important roles in identifying and creating a valuable product or service.  However, what has happened to the Customer role?  I contend the Customer is the most important role in the Agile world.  Does it seem to be missing from many of the discussions?

While not always obvious, the Customer role should be front-and-center in all Agile methods and when working in an Agile context.  You must embrace them as your business partner with the goal of building strong customer relationships and gathering their valuable feedback.  Within an Agile enterprise, while customers should be invited to Sprint Reviews or demonstrations and provide feedback, they should really be asked to provide feedback all along the product development journey from identification of an idea to delivery of customer value.

Let's remind ourselves of the importance of the customer.  A customer is someone who has a choice on what to buy and where to buy it. By purchasing your product, a customer pays you with money to help your company stay in business.  For these factors, engaging the customer is of utmost importance.  Customers are external to the company and can provide the initial ideas and feedback to validate the ideas into working products.  Or if your customer is internal, are you treating them as part of your team and are you collecting their feedback regularly?

As you look across your Agile context, are customers one of your major Agile roles within your organization?  Are they front and center?  Are customers an integral part of your Agile practice?  Are you collecting their valuable feedback regularly?  If not, it may be time to do so.