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 3rd Agile Principle (Frequent Delivery) 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 third 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?  

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale is the third Agile principle. This principle promotes the ability that when customers believe there is value in what is built, it can be immediately delivered. Identifying the elusive customer value means you can release it when the customer wants it. If it is delivered too early, the customer may not be ready for it; if it is too late, the market opportunity is missed. 

Agile thinking includes a fluid world, where changes are continuous welcome, and teams have the capability of releasing frequently. This ability to frequently release, highlights the importance of having processes and infrastructure to help with continuous integration, build, and test. This ability assumes a level of automation that needs to be in place. Automated testing increases the possibility of testing the functionality as is reasonable, including the capability of performing non-functional testing such as performance testing, load testing, and more. 

What actions exhibit frequent delivery?  

• An established and positive relationship with customers
• Iterative framework with Sprint Reviews to incorporate feedback quickly 
• A release capability to incrementally and rapidly deploy software 
• Continuous integration supported by a merging process and configuration management system 
• A continuous build process supported by an automated build management system 
• Test automation infrastructure that can support continuous testing  

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, do you really believe in the principle that focuses on frequent delivery?

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

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

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

Importance of Agile Readiness for a Transformation

To be a successful farmer, one must first know the nature of the soil.  —Xenophon, Oeconomicus 

Have you ever been in a daily stand-up where everyone was reporting status to the one person they thought was the leader or where most didn’t know why they were doing a stand-up every day or ever? This highlights a lack of readying the mind for what a daily stand-up is and why we are doing it.  A lack of readiness can stall or halt an Agile transformation because people aren’t in the right frame of mind for transitioning to Agile.

Readiness starts the moment when the question, “Is Agile right for me?” is asked. Readiness activities can help you better determine if Agile is right for you. Agile readiness is akin to conditioning and fertilizing the soil before growing the seeds. It is good to take a realistic look at the conditions of the fields, equipment, and people. Conditioning the mind with an understanding of Agile principles improves the ability to adopt Agile in a way that leads to truly being Agile. Strengthening the soil helps improve the physical qualities of the soil, especially in its ability to provide nutrition for plants. They can make poor soil more usable and rebuild soil that has been damaged by improper management.

This is exactly what readiness activities can do. Examine the condition of the environment where Agile is being considered. Understand and educate people on the Agile values and principles and the business benefits that can be gained. Gauge the buy-in from leaders and the willingness and capability of teams. Determine if openness or command-and-control behaviors are being exhibited (explicitly or implicitly). Understanding this context provides valuable insight into ways to adapt and move forward.  What we learn, can help shape the agile implementation according to the condition and context of an organization.

You do not need to complete all readiness activities to begin implementing, but I have learned that if you begin implementing Agile, you quickly realize that you will need to address these areas, so it is better to be proactive. With this in mind, an iterative approach may be used. Here are high-level readiness activities that you may consider. As always, feel free to adapt this list of activities if it benefits you.

• Establish a common understanding of Agile.
• Construct and share the drivers for an Agile organizational change.
• Provide Agile mindset education based on Agile values and principles. Then determine subsequent educational needs.
• Add “Customers and Employees Matter” to the company vision and share this with employees.
• Gauge levels of executive and stakeholder buy-in.
• Establish an overall strategy and backlog for the agile transformation.
• Determine team willingness and capability.
• Identify allies, champions, and subject matter experts (SMEs) and resources.
• Identify and establish agile roles and organization.
• Establish agile frameworks and practices that may be used. (This should not be a prescriptive model but a flexible framework, because each team is different.)
• Establish done criteria, user story framework, and sizing techniques.
• Craft measures of success and general metrics.

A benefit of readiness activities is that you can adapt the transformation approach based on what you learn. Another advantage is that if you find that there are challenges in an area, you can address and improve the situation. For example, you may find that there is not a clear driver for moving to Agile. This can initiate discussions on the business benefits of Agile, motivational factors behind the move, and what it takes to be Agile.

Consider Agile readiness activities as the first increment in your transformation. The outcome of Agile readiness and what you’ve learned can help you better plan the next iteration. Finally, I recommend that once you embark on these activities, you initiate periodic check-ins to gauge progress, mitigate roadblocks (such as risks and issues), and adapt along the way.

Are there Benefits for adding ChatGPT as a team member?

There is evidence that ChatGPT can be beneficial in helping you do your work. Involving ChatGPT today is already occurring in repetitious, creative, and diagnostic type work. Some say it’s inevitable and you should learn to work with many forms of AI. Current uses have shown that it can improve work efficiency, assist with tedious tasks, help you with creative tasks, and facilitate learning. We are also learning that because ChatGPT is based on a large language model, it can act as your assistant; providing personalized responses based on your inputs, helping you work smarter, and boosting your productivity.

As it can help an individual in their work, how about helping a team?  In this article, I explore how helpful ChatGPT can be for a team. In other words, I suggest making ChatGPT a member of your team. ChatGPT is an artificial intelligence chatbot capable of mimicking human-like conversations so why not be a member of your team? As mentioned, ChatGPT has been recognized to boost productivity so let’s consider the context of a software engineering team who are producing new features and correcting bug fixes to the code base.  To consider this, here are the potential positives, negatives, and limitations of incorporating ChatGPT as an engineering team member. Here are some considerations:

First, let’s start with some Positives:

• Multi-tasking: ChatGPT can handle many questions, inquiries, and tasks simultaneously allowing certain work to be handled more efficiently and scaled to a higher volume of work.  
• Quick feedback: ChatGPT provides quick feedback to questions and inquisitions allowing for more input for potential better options and decision-making.
• Availability: ChatGPT is technically available 24/7 and can work while team members rest allowing for busy work to get completed and tasks to be ready for team review when they are back online.
• Scalability: As an AI, ChatGPT can handle a high volume of inquiries without experiencing fatigue or requiring breaks.
• Database of information: ChatGPT has access to a vast amount of information and can provide accurate and up-to-date answers to team members' queries.
• Human Languages: ChatGPT can speak in multiple languages and can accommodate global teams across multiple boundaries and locations.  
• Programming Language: ChaptGPT has the potential for programming capability across various language platforms.  

Next, let’s move to the Negatives:

• Time from Team Members: Working ChatGPT will take time from some team members. A buddy for ChatGPT will need to be designated to help provide context for ChatGPT, line up tasks, reduce ambiguity of the requests, verify and validate the work done by ChatGPT, and more.
• Lack of emotional intelligence: ChatGPT lacks emotional understanding and empathy, which may limit its ability to provide refined and empathetic output to team members.
• Limited contextual understanding: ChatGPT will struggle to understand the context in which you are working including the complexity of the work, potentially leading to misunderstandings or incorrect responses.
• Bias and completeness fn training data: the database from which ChatGPT pulls has already shown some bias based on patterns and data provided which means it may generate reasonable responses but may be incorrect or biased if not carefully reviewed.
• Lack of creativity: Because ChatGPT pulls from existing data and patterns, this limits its ability to generate genuinely innovative or creative ideas.

Finally, several considerations should be factored in. The first is ethical considerations as ChatGPT may inadvertently generate or reinforce biased or discriminatory responses due to its training data (which includes such biases). Careful monitoring and bias mitigation strategies will be necessary. The second consideration is legal and compliance challenges.  Incorporating ChapGPT into a product team may raise legal and compliance concerns, particularly in regulated industries that require human input, oversight, and/or accountability.

It's essential to consider these factors and strike a balance when integrating ChatGPT or any AI model into a product team. Human supervision, ethical guidelines, and continuous evaluation can help mitigate the limitations and ensure optimal utilization of AI technologies like ChatGPT. Now it is time for you to wrestle with this question: Are there Benefits of adding ChatGPT as a team member? Hopefully the overview, positives, negatives, and considerations can help you with your answer. 

----------

If you are interested in learning more about ChatGPT in relation Agile, Teamwork, or experimentation, consider reading these additional articles:

• A Discussion with ChatGPT about Agile 
• Are there Dangers with ChatGPT for Agile? 
• How to Experiment with ChatGPT 

How to Experiment with ChatGPT

As ChatGPT continues to make waves, is it time to learn more about it? One way to approach this is begin experimenting with ChatGPT within your context.  Learn where ChatGPT can help and where it can benefit you. In other words, what do you want to get out of ChatGPT? This allows you to test your hypothesis and the surrounding assumptions to provide knowledge and insight into whether (in this case) ChatGPT can help you or not. Here is an example.

Start with the question: Can ChatGPT help my team improve? Validate this question. Conduct preliminary research to gauge if this is relevant for your team. Start by finding out if team members are interested in using ChatGPT. This can also help you identify assumptions and if there are any other variables in play that can impact the direction of the experiment. It can also help you narrow down an area that you think ChatGPT can help.  After discussion with the team, team members believe that ChatGPT can help in retrospectives

Craft a hypothesis in a clear sentence on what you expect to find: Include ChatGPT in the retrospective can lead to better root cause analysis.  Some team members had an assumption that ChatGPT could provide root cause analysis capabilities. A hypothesis can help you validate whether ChatGPT can provide better root cause information. You can also use the “if… then” form: if we use ChatGPT during our retrospective, it will provide better root-cause analysis results, leading to more effective actions for improvement.    

Craft the experiment. Now that you have a sturdy hypothesis, it is time to craft your experiment. Describe the steps through your experiment. To do this, consider how long the experiment will run and who will be involved.  In this case, you decide to include ChatGPT in the next three retrospectives in order to get a more meaningful set of results and to have time to determine if the actions are leading to more effective results. Determine who will use ChatGPT during the retrospective and how the questions and statements will be written. Also consider the metric you will use to validate your result and what success criteria you will use to determine if the hypothesis was true (or not).  At this point, it is time to run the experiment. 

Run the experiment. An experiment should be considered as recognized effort and categorized as real work to track in your backlog.  Enact the steps listed in your experiment. Capture observations along the way and results upon the conclusion of the experiment. Get together with those who are involved in the experiment and determine what you’ve learned. Ask the question, did what we learn validate the hypothesis (or not)?  Then determine what decisions you will make as a result of this experiment. In this case, should you to continue using ChatGPT for retrospectives (or not)? Determine if there are any next steps. 

In conclusion, if you are thinking about ChatGPT, the key is to experiment. ChatGPT is a tool like other tools that may benefit you. Brainstorm where ChatGPT can help you in your context. Use the experiment to see if it does. Consider multiple experiments so that you build working knowledge of ChatGPT in your environment and working context.

---------

If you are interested in learning more about ChatGPT in relation Agile, Teamwork, or experimentation, consider reading the following articles:

• A Discussion with ChatGPT about Agile 
• Are there Dangers with ChatGPT for Agile? 
• Are there Benefits for adding ChatGPT as a team member? 

A Discussion with ChatGPT about Agile

I had a good discussion with ChatGPT about two weeks ago. I started by asking “What is Agile?” The response was that “Agile is a methodology” with a bit more details. While technically incorrect, given the amount of information and vectors it pulled from, it wasn't completely wrong. What I mean by this is that many people, including some “Agile experts”, refer to Agile as a methodology which is incorrect. Depending on where ChatGPT is pulling this information from, this isn’t a surprise.   

• My response: “Agile is a set of values and principles. Some Agile information is not aligned with Agile values and principles and instead rely heavily on Agile processes and methodologies or people's misinterpretation on what is agile”.  
• ChaptGPT's response: You are correct. Agile is indeed a set of values and principles outlined in the Agile Manifesto, and it emphasizes flexibility, collaboration, iterative development, and customer satisfaction. However, misinterpretation or a focus solely on Agile processes and methodologies can lead to a deviation from these values and principles.

I was happy to see that it was aware of the Agile Values and Principles as this is how Agile is defined by the Agile Manifesto which is the seminal information defining Agile. And as I mentioned in my previous article, The Dangers of ChatGPT to Agile, there is a lack of quality evaluators on the numerous Agile articles and presentations in cyberspace that indicate if the information provided is right or wrong, good or bad.

Two weeks later (today), I asked ChatGPT the same question, “What is Agile.” This time it included the Agile Values and Principles as part of its long-winded response that included:

"Agile is an iterative and incremental approach to project management and product development that emphasizes flexibility, collaboration, and continuous improvement. It was created as a response to traditional, plan-driven project management methodologies that often struggled to adapt to changing requirements and deliver value in a timely manner.

Here are some key aspects of Agile:

1. Values and Principles: Agile is guided by the Agile Manifesto, which outlines four core values: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. These values prioritize human-centric approaches and adaptability.
2. Iterative Development, 3. Cross-functional Teams, 4. Continuous Improvement, 5. Customer Collaboration, 6. Flexibility and Adaptability" (Note: I removed the details of 2 thru 6 from ChatGPT as this wasn’t relevant to this article).  

While ChatGPT will continue to develop and response to my queries, I am happy to see that it is using my (and others’) input to fine-tune its language model and improve its responses.

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

If you are interested in learning more about ChatGPT in relation Agile, Teamwork, or experimentation, consider reading these additional articles:

• Are there Dangers with ChatGPT for Agile? 
• How to Experiment with ChatGPT 
• Are there Benefits for adding ChatGPT as a Team Member?

The Meta of getting to Small in an Agile World

If you are Agile in the Product delivery and software development space, there is strong emphasis on thinking small.  This means decomposing work to small pieces to allow for iterative and incremental delivery and eventually the continuous flow of work. While this sounds straight-forward, in practice, it is hard because it disregards the challenging mindset shift that must occur to get people to think small. 

It is important for Agile teams, coaches, and leaders need to understand for those who have never decomposed their work to “small” size chunks, they have little idea what that means and it may take time. This article focuses on several reasons why “decomposing the work to small pieces” is challenging and the meta surrounding the concept of small.

Small is mindset shift  

Imagine that you have never considered what is small and someone says, “think small!”  This is meaningless without any context or experience in “getting to small”.  To achieve the concept of understanding small bite-sized pieces or work, there is mindset change that must occur.  Imagine if you were piloting a plane for the first time and your instructor says, you must go “fast” to take off.  What does fast enough mean if you’ve not done this before? If you only ride a bicycle, then fast may mean 25 mph (or 40 kph). However, in order to take-off, fast means 75 mph (or 120 kph) for a propeller plane and 170 mph (or 275 kph) for a jet.  There must be a strategic steps to shift the mindset to think differently that includes allowing the team time to learn and experience their way to small. 

Small is Relative 

What is “small” will be different depending on the type of work a team is doing. There is back-end, middleware, front-end work and more. Each team must gauge what is small based on their work. Also, what is small will differ from team to team and is relative to team size, talent, and experience. What is small must be specific to each team. Management must not compare sizes across teams as this will deteriorate the relative sizing for the specific teams.

  
Small is Complex 

Creative work like building new products and services (or features therein) are considered complex (per the Cynefin framework) as there are unknowns and “unknown unknowns”, ergo requiring a "probe–sense–respond" approach.  Many will translate small to days of work. But translating small to time of work disregards the complexity and unknowns of the work. In an Agile world, we consider not just effort, we look at complexity of the work (e.g., what is known and unknown), and any risks involved in the work (e.g., what skills, experience, tools, infrastructure a team has and more specifically what they don’t have.  What this means is that to identify small work, you must look at effort, complexity, and risk so it isn’t straight-forward.

Small is Imprecise 

In an Agile world, we don't pretend to think that we can have precision in our sizes. We want good sizes but we have to move away from the traditional mindset where we think we can provide accurate estimates. If it isn't correct, this is actually okay as we’ll soon learn more about the work.  When you size the work within an iteration (aka, sprint) and the iteration is done, you will quickly build a historical database of sizing and will learn more about the work.  The very next iteration, you will have learned whether you were over or under for a size and when similar type work comes along you have input for the future sizing of work.  In other words, “don’t sweat the sizing”. 

Summary

When transforming to Agile, there is a shift to to small pieces of work allowing for iterative and incremental delivery of the work. Small is challenging for teams that have not had to work decompose to small. Understanding the meta around getting to small can help coaches, teams, and leaders navigate the challenges knowing that it is a mindset shift, it is imprecise, it is relative to the work and each team, and is complex.  

Are there Dangers with ChatGPT for Agile?

How will ChatGPT impact Agile? This article discusses ChatGPT and its implications to Agile in the industry today. ChatGPT is taking the internet by storm and hard to ignore. Because of this, it cannot be ignored by those in the Agile field. What are the implications of ChatGPT on Agile? Here is a brief summary of what is ChatGPT and a review of what is Agile and its current journey.

What is ChatGPT?

ChatGPT is an artificial intelligence (AI) chatbot-type tool developed by OpenAI. It is adept at producing human text-based output on the input it is given. This model incorporates a large body of text data and can create responses to questions, write articles, and more. The challenges with ChatGPT are that it is only as good as the “large body of text data”, can be used maliciously and with bias, can spread misinformation, and is ethically complex in its application and future application. This applies to any field that people may use it for including Agile.   

What is Agile?

Once upon a time (in 2001) Agile was unveiled based on the Manifesto of Agile Software Development which is comprised of Agile Values and Principles. The objective of articulating the values and principles is to apply them in the form of an Agile transformation to derive better business results. However, the manifesto does not provide guidance on how to apply Agile. 

Soon, a number of processes and methods (e.g., XP, Scrum, Kanban, SAFe, etc.) were established to construct and apply agile ways of working. Agile has also spawn a number of certification programs in an attempt to educate people in Agile ways of working, in some cases aligned with a process or method. During this same time, Agile coaches were educated to help their own companies and Agile consultancies to help other companies apply Agile ways of working. The Agile movement has grown and expanded in a number of fields beyond software development.  After over 20 years, what are the results? The challenges are three-fold.  

• First, the current state of Agile is underwhelming. The most recent State of Agile Report (16th Annual – 2023), tells us the following. Only 18 percent of organizations implemented Agile for all the teams. Around 50 percent of respondents report that less than half of their teams are using agile, and 84 percent acknowledge that their organizations are below a high level of competencies. There is clearly plenty of opportunity for growth.
• Second, some of the Agile savvy (e.g., coaches, consultants, leaders, managers) seemed to lack an understanding of what is agile. In an Agile study where 109 agile professionals answered a survey on Scrum events and Agile principles, 59% could name 3 or more of the five Scrum events, while only 11% knew 3 or more of the twelve Agile principles. This is quite astounding. And they didn’t need the full statement of the principle but got credit for even the key words of the principle. The concluding hypothesis is that the reason there is such a lack of awareness of Agile principles is that there is much less focused on the mindset and culture and maybe too much focus on the mechanics.
• Third, the implementation of an Agile transformation is complex per the definition provided by the Cynefin framework. Agile transformations are neither linear nor predictive. It depends on the readiness of the culture and willingness of its leaders in their ability to move forward. Complexity means that it is not clear on what the best next step is until you act, ergo you need to probe, sense, response your way forward. This is why experimentation helps reveal what is possible each step of the way. You must both meet the company and teams where they are and help them determine what is the next step to further the transformation.  

What this tells us is that there are great opportunities for improvement and that there is no easy way to apply Agile, no one-size fits all, and no clear roadmap. Why? Because every organization is different due to their current culture, size, fields, practices, and more. 

Implication of ChatGPT and Agile

Now that we have an overview of both topics, the question is what are the implications of ChatGPT to Agile (and vica-versa)?  I’ll start by saying “What you put in is what you get out”. ChatGPT is only as good as the “large body of text data” available to pull from. The good news is that today there are reams of text data on Agile. The bad news is that there is no rating system on the quality of most of the Agile related information. With the advent of blog’s, there is a large body of unverified knowledge that enters into the “large body” of available data. What are the implications of this? 

• Arguable Quality of response - The quality of ChatGPT generated articles and answers should be read with a grain of salt. This isn’t a “knock” on ChatGPT, and instead it is due to the quality of the body of text data that ChatGPT draws from. And the reality is there is no one right way of applying Agile.  
• Propensity for Misinformation - There is a danger of misinformation and abuse of those who use ChatGPT to bias their responses. Some may be accidental as the body of text being pulled in isn’t broadly approved or agreed upon. While I don’t expect that most will be intentionally abusive, do keep in mind, there is money to be made in selling agile so bias may be seen.  
• Not doing your own Research - While you may want to occasionally use ChatGPT, it is better to learn from the body of Agile knowledge out there (e.g., books, articles, presentations, seminars, etc.) according to the areas that will benefit your current needs in your Agile transformation or need. In other words, do your own research so you can critically judge the quality of information that gets generated.
• Taking Agile Jobs - Can ChatGPT take jobs away from Agile Coaches and Consultants? This is unlikely as a significant part of an Agile transformation include coaches and consultants who have been on a transformation journey that can help companies navigate the complexity of both the current needs and the anticipation of near-term needs. ChatGPT cannot “read the room” like an Agile Coach. Should a company think that ChatGPT will be “enough”, it highlights that they don’t understand the complexities of a transformation and what it takes to change culture.

Summation

Now that you have some background, let us again turn to the question, “how will ChatGPT impact Agile?” There will be those that use ChatGPT to provide answers for Agile theory and questions. If you want to write an Agile article, it will help provide input and insight, although you have to be aware that the value of the information is only as good as what it pulls from. Think of ChatGPT as another resource to help you think through your ideas on agile topics and how it may help you in your Agile transformation. However, just remember, it is just a tool like other tools.     

It is unlikely that ChatGPT will take over Agile roles and the art of the transformation. A big part of Agile transformation is discovering, observing, and experimenting on what will work and what will make progress. Remember, when defining Agile, it really implies a transformation. This is a combination of doing agile and more importantly being agile. This means transforming mindset and culture. It is currently unlikely that ChatGPT will have this capability as transformations are complex with the real need to experiment (e.g., probe, sense, response) toward progress.  Coaches and consultants are still important to help transform organizations and more importantly to help leaders and teams make the mindset-shift to truly becoming Agile. 

-------

If you are interested in learning more about ChatGPT in relation Agile, Teamwork, or experimentation, consider reading these additional articles:

• A Discussion with ChatGPT about Agile 
• How to Experiment with ChatGPT 
• Are there Benefits for adding ChatGPT as a team member? 

Breaking Bad Story Point Anti-Patterns

There is occasional controversy in the Agile coaching community on whether to apply Story Points on user stories. This often stems from the challenge where some think that story points are a direct replacement for estimation and an expectation of precision while others suggest that instead of story point sizing, we should focus on focusing on small pieces of work. In other words, when applying a practice (e.g., story points), a bad pattern is implemented which is opposed to the way practice is meant to be applied. This is known as an anti-pattern. Anti-patterns lead to results that are counterproductive to the intent of the practice and reduce their effectiveness. In other words, not good. 

What is Story Point Sizing? 

Before we go further, let’s take a moment to define what is a story point? A story point is a unit of measure describing the size, complexity, and risk to gauge the amount of work needed to complete a particular user story. 

Story points are also a relative measure to a specific team. Every team creates their own story point sizing framework based on the type of work they do, the skills and experience of the team, and what they personally perceive to be a small, medium, or large amount of work. The team collaboratively determines the story points for each story based on its perceived size, complexity, and risk. 

Story points are often correlated with small, medium, and large sized work. Some use the Fibonacci as it provides a numeric distribution that can be used to differentiate between sizes of work typically using 1, 2, 3, 5, 8, 13, 21. When using Fibonacci numbers, 1, 2, and 3 are aligned with small work, 5 and 8 are medium sized work, and 13 and 21 denote large pieces of work. 

Velocity is a metric that can help a team understand their sustainable pace by identifying the amount of story points of work a team can complete in an iteration. In each case (e.g., story points and velocity), this is why you should not compare the story point velocity across different teams. Story points and velocity are very specifically a team measure and should not be tampered with by those outside of the team. 

Anti-patterns of applying Story Points 

The reason there is concern surrounding applying story points is the ways it gets applied. As mentioned, story points are a combination of size, complexity, and risk of that specific piece of work (aka., user story). This means they are not meant to be used as a predictor or for accuracy. Here are several anti-patterns of story points in the way they get applied: 

• Hours-Days Effort anti-pattern - Some apply story point sizing as if it is nothing more than an estimated effort of hours and days. There is often a direct translation of number of hours and/or days and forget (or ignore) the complexity, risk, and uncertainty in the work.  
• Pretend Certainty anti-pattern - There is often ascribed a sense of certainty when applying story point sizing where it gets used to predict when work will get done. At best, it can help with understanding progress, but you would never estimate “all” of the work up front anyway as priorities (and requirements) tend to shift so it would be a waste to do so. 
• Pretend Precision anti-pattern – There is precision when using story points which isn’t appropriate. The numbers that story points represent are meant to be ball-park numbers as it is an amalgamation of size, complexity, and risk. 
• Contrived Comparison anti-pattern – Some organizations attempt to compare story points and velocity across teams even though they are relative to the team’s composition and the type of work they focus on. This is inappropriate and decreases the integrity of story points and velocity. 
• Effort Tampering anti-pattern – This occurs when someone outside of the team (usually management) attempts to influence the amount a work a team does by insisting on improvement. This impacts the integrity of the story point sizing framework and the velocity data as those are meant specifically for that team to have meaning. 
• Inflation anti-pattern – This can be the result of when someone outside of the team applies the Effort Tampering anti-pattern by attempts to make the team “work harder”. The result may be that the team inflates their numbers to ‘satisfy’ the influencer and effectively impact the integrity of the story point sizing framework. 
• Productivity anti-pattern – This is when story points and velocity get conflated as a productivity measure by those outside of the team. They are not productivity measures and will warp the intent of both story points and velocity. 

Mending Anti-Patterns  

The best way to eliminate or reduce anti-patterns, is to first understand what anti-patterns look like (see Anti-Pattern section above and search of other information on anti-patterns). Then do detective work to uncover what anti-patterns may exist. Follow this with determining an action to remove or eliminate them. You can do this through a theme-based retrospective where the focus is on identifying anti-patterns. 

Anti-patterns within an organization are more commonplace than you think. They are often due to a lack of clarity of what are story points, how they should be applied, and a lack of awareness that they are specifically a team-based measure. There may also be management or team member influence to use the practice or technique incorrectly. If too many of these anti-patterns exist, then the value of using story points as a team measure and as an instructive tool to help team gauge what is considered small diminishes.

Company Success with an Enterprise Pipeline of Ideas

The Enterprise Idea Pipeline provides you with an end-to-end view of the flow of ideas from the moment they are recorded to when they are released.  It is meant for the enterprise to respond to high value ideas the moment they came so the enterprise does not miss the idea’s window of opportunity.  

It provides three primary benefits to an enterprise.  First, it is a channel that provides an end-to-end flow of ideas from the moment they are recorded to when they are released and reflected upon.  Second, it is the enterprise level portfolio backlog of ideas.  Third, it is meant to highlight high value ideas the moment they came in so that the enterprise does not miss the idea’s window of opportunity.  

The culture needed for the Enterprise Idea Pipeline is one where the enterprise immediately considers ideas as they come in because they are based on a current problem or opportunity.  You don’t wait for the next budget cycle to consider the idea. The pipeline is a more adaptable way of managing the portfolio of work across your enterprise since ideas can be admitted anytime and feedback may adapt its priority or reshape the idea.  Also, the pipeline brings enterprise-wide visibility and transparency to the work occurring within an organization.

Before moving further, what is an idea?  An idea is something that is deemed as valuable and has yet to be created.  The moment it is recorded, it may be small or large.  Depending on its level of customer value, it may become work that is worthy of evolving into a product or service or a significant feature of each.    

The pipeline is a working example of the delivery axis focused on delivering customer value as illustrated above. As the delivery axis represents the end-to-end flow of customer value from the recording of the idea to the point where it is released and reflected upon so is the Enterprise Idea Pipeline. 

The Enterprise Idea Pipeline can be known by different names such as a portfolio backlog, enterprise kanban board, and idea pipeline. What makes them all similar is that they hold the big ideas that may eventually (or immediately) be worked on by teams.  The Enterprise Idea Pipeline acts as the parent and feeder to all product backlogs and helps you connect strategy and ideas to user stories (and even tasks) and visa-versa.  

The pipeline is primarily used in medium to large companies, when visibility is needed to make investment decisions across portfolios to better understand where the highest value work lives.  It also helps when there are dependencies across multiple products, or when ideas do not have an obvious resting place in a product backlog.  When an enterprise is small and made up of a singular product, then the product backlog acts as the enterprise idea pipeline as these are the ideas that may be included in the future of that product.  

To learn more about applying an Enterprise Pipeline of Ideas in your company so you can be more customer value driven, feel free to reach out to Mario Moreira at: https://www.linkedin.com/in/mariomoreira/

Has Covid-19 boosted Business Agility?

Written by Nawel Lengliz and Mario Moreira

Economists might argue that the Covid 19 crisis caused a lot of disruption to companies. I strongly believe the pandemic has helped companies improve the way they collaborate, especially via remote work, which boosted their business or, more precisely, their business agility. Let me explain how.

First and foremost, remote work has helped teams in democratizing information sharing. In effect, by using digital tools, it has become easier to have access to information, to briefings of decisions or to digital white boards in the sense that people do not have to be physically present in meetings to understand the meeting outcomes.

Democratizing information sharing has paved the ground for a natural transition to something we believe in a lot in the Agile community: Visualization of the work. This technique, borrowed from lean manufacturing, consists of using a board that shows all the work being done via cards representing each piece of work, is simple and very powerful. Besides creating a shared understanding on who is doing what within the team, using boards helps to visualize problems in the system of work. For example you may find there is too much work in progress (WIP), work with competing priorities or tasks that have remained stagnant. Therefore, by making problems visible, it becomes easier for teams to discuss problems and try to overcome them by continuously improving their system of work. 

Another advantage to the transition to remote work is the ability to have worldwide access to talent. I remember when Covid 19 broke out, I was part of a global company and we wanted to create an Agile community of practice for the french speaking region. Thanks to remote collaboration, we were able to include skillful people located in francophone Africa. This cross-border collaboration allowed very creative ideas to emerge and spark new perspectives. We were all energized by the diversity of our backgrounds and experiences.

Finally, using digital tools during retrospectives or feedback sessions makes it possible for teams to write notes and share their ideas while building trust. This ability to speak up without fear helps to improve the Psychological Safety climate within teams. According to Amy Edmondson, a famous psychology researcher, creating psychological safety is the number one condition for creating high-performing teams.

Nevertheless, people working remotely sometimes miss face-to-face collaboration (I am among them). In fact, being in the same room creates energy as people communicate not only with words, but also with their body language. However, as food for thought, according to some research, flying generates an equivalent of ¼ tonne of CO2 per hour. Is it really worth generating such an amount of pollution to attend a couple of meetings over a day?

In summary, the Covid 19 pandemic urged companies to try or improve new ways of working remotely with such results as democratizing information sharing, making work visible, accessing talent everywhere and using digital tools to foster psychological safety. These techniques have helped companies move faster, be more inclusive and promote collaboration that helped employees to become happier and to our planet being more ecologically healthier. 

• Learn more about Nawel Lengliz at: https://www.linkedin.com/in/nawel-lengliz-111b795/
• Learn more about Mario Moreira at: https://www.linkedin.com/in/mariomoreira/

Good and Bad Reasons for Moving to Agile

There are various reasons behind moving to Agile. Some are proactive and some are reactive. Proactive motivations tend to be accompanied by a greater understanding of the business benefits of Agile and the culture change it implies. However, this is not always the case. The reasons behind the motivation can determine your chances to achieve a real transformation. Let’s take at a notional proactive-reactive model that looks at some motivations for moving to Agile and what you can do to enhance your chances of gaining the business benefits of doing so.  

• "It’s the trendy thing to do." Agile is popular, so we should do it. This is reactive and not a strong motivator for change. When another trend comes along, Agile may be abandoned. Agile may be seen as a hollow initiative and some may wait it out to see if it will go away. It will be important to investigate the benefits of Agile to see if it is right for you. Then determine if real commitment can be gained. 
• "The competition is doing it." Others are doing it, so we better do it. This is reactive. Although it may provide a driver for change, it does not provide clarity on why Agile was chosen. Some will question why what a competitor does is good for us. What happens when they do something else? It will be important to investigate the benefits of Agile to see if it is right for you. 
• "We need to reduce costs." This is a reactive and insufficient reason whereby Agile is seen as a tool to cut costs and maybe the workforce. This will not lead to the business benefits of moving to Agile. Although it may be an outcome, other benefits of Agile may be gained if you are willing to adapt the culture. 
• "What we have isn’t working." We’ve been using another process to deliver software and it isn’t effective. This is a reactive reason with little understanding of Agile, but it may provide an initial motivation for change. However, moving to Agile without understanding what it takes may lead to a failed deployment. It is best to understand the root cause for the failures in the past, because this can affect your change to Agile. 
• "We hope to increase employee morale." This is a proactive reason based on an understanding of the importance of employee engagement and empowerment to improve morale. Validate that there is real commitment to empowering employees and self-organizing teams. 
• "We hope to improve productivity." This is a proactive reason when the goal is to empower employees and help them improve productivity. The danger is that management may believe that Agile is something someone else must do to increase productivity or the real intent is to make employees work harder. The other challenge is that productivity may come at the expense of sacrificing quality. It will be important to investigate all of the benefits of Agile, not just productivity. 
• “We aim to decrease time to market.” This is a proactive reason in which Agile is seen as a way to shorten release cycles. If there is an understanding that this implies a change across the organization to get from market idea to release and it is meant to satisfy the customer, then this is a good starting point. It is still important to discuss the benefits of Agile to see if it is right for you. 
• “We want to deliver customer value.” This is a proactive and genuine reason if Agile is seen as a way to engage the customer and understand value. Validate whether there is a real commitment to delivering value and an understanding of the need to change organizational behaviors and processes to get there .
• “We believe in the Agile values and principles.” This is a proactive and genuine reason where Agile may be seen as a positive change in company vision and behavior. Validate a drive toward continuous customer engagement and employee engagement that can help gain the business benefits that Agile can bring. 

In all of these cases, you need to validate commitment to the values and principles and the culture and business change it entails. Once the initial motivation is understood, we can work to adapt it with the goal of better gaining the business benefits of going Agile.  

What Color is receptive to Agile?

In Frederic Laloux’ book “Reinventing Organizations”, he describes organization paradigms as an evolution in human consciousness.  Examining these paradigms can provide insight into organization attributes that lend themselves to an Agile culture.  The early paradigm starts with the Reactive-Infrared paradigm and then Magic-Magenta paradigm.  Both of these embody the early stages of humankind which include smaller groups such as tribes of people.  This is followed by the Impulsive-Red paradigm which has the guiding metaphor of a wolf pack illustrated by tribal militia, mafia, and street gangs. 

The Conformist-Amber has the guiding metaphor of an army illustrated by a church hierarchy, military, and most government agencies.   Next is the Achievement-Orange which has the guiding metaphor of the machine illustrated by multinational companies and charter schools.  A majority of the organizations today tend to reflect a red, amber, or orange paradigm.

From an Agile perspective, it is after this where it becomes interesting.  A general alignment can be made to two of the latter paradigms that may be considered as behaviors you would hope to see in an Agile enterprise. These are the Pluralistic-Green and the Evolutionary-Teal paradigms. 

The Pluralistic-Green organization strives to bring equality where all viewpoints are treated equality irrespective of position and power.  It uses the family as the guiding metaphor where we are in it together and help each other out. One of the breakthroughs of a green organization is Empowerment. Empowerment is focused on pushing a majority of decisions down to the frontline (e.g., where the work is).  This is directly aligned with Agile thinking where there is a focus on pushing down decision-making to the lowest possible level where the most information resides regarding the topic.  

Another breakthrough of a green organization is that it is a values-driven culture. This very much aligns with the importance of leading with Agile values and principles. The green organization understands that a shared culture where leaders play by shared values is the glue that keeps those in organizations feeling appreciated and empowered that can lead to extraordinary employee motivation.  

The Evolutionary-Teal paradigm emphasizes that the organization adapts as circumstances change. Its metaphor is one where the organization is a separate living organism. In a teal paradigm, titles and positions are replaced with roles, where one worker can fill multiple roles. This is very much like the concept of the cross-functional team within an Agile structure.  This paradigm emphasizes the capability to self-organize around the organizational purpose.  The hierarchical structures are replaced with self-organization focusing on the smaller teams. This is aligned with the Agile principle of self-organizing teams (aka, the best architectures, requirements, and designs emerge from self-organizing teams).  

To read more about how the colors of Pluralistic-Green and Evolutionary-Teal can benefit an Agile journey, consider reading The Agile Enterprise: The Agile Enterprise: Building and Running Agile Organizations. You can also learn more about colors of organizations by reading Reinventing Organizations. 

Hiring for the Culture of your Future

As an Agile Consultant, I occasionally help companies hire for talent as I’m transforming companies (e.g., an Agile transformation, business transformation, digital transformation or similar). When I’m helping with interviewing or hiring talent process, the interviewers circle back together to discuss the candidate. I often hear things like “They don’t seem to fit our culture”. Sometimes, there is a question built into the interview questionnaire asking, “Are they a cultural fit?”. 

When a company is satisfied with their culture, I can understand that you would align with the concept of hiring for cultural fit.  However, when you are working through an agile, business, or digital transformation, this implies that you are also transforming to a different culture with new ways of working. When you say “hire for a cultural fit” it needs to be to the new culture that you want.

For example, if the culture is more command and control where work is prescribed upfront, then the work culture tends to be very individual driven (I have been assigned my task and I will work on it) with little feedback is asked for (do the work and get it done by the deadline). If you are transforming to Agile ways of working, you need a much more collaborative and team-oriented culture where people are pairing up on tasks, helping each other, and where feedback is expected. Hiring for the former (command and control type culture) will not help you get to an agile culture of collaboration.  

If you are going through any type of transformation as a company, include a theme or work on re-evaluating the hiring process. Take a look at your standard interview questions and adapt them for the culture that you want. Also, describe the type of people that will fit your future culture (e.g., collaborative, team-oriented, etc.) and share this with the interviewers.  This will help embed your current culture with the people that will support the culture you desire for the future.    

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

Agile Brevity

When working within an Agile context, there is an emphasis on getting work done and meeting the outcomes of the customer needs. The work is typically structured around various Agile ceremonies depending on the methodology or process a team is using. Key to these ceremonies is to keep them concise. In order to do this, often timeboxing is introduced. However, timeboxing is only as effective as the people’s abilities to keep their discussions concise. I call this technique “agile brevity”.

What is agile brevity?  It is a speaking technique that is both art and skill focused on keeping one’s comments as clear, concise, and value-added within the context of the session at hand. This means that the brain must be hyper-focused on the context and purpose of the session and speaking with agile brevity within that context.  It then means that the person must consider what is the most important thing of value to say that will help progress move forward. This leads to more productive and collaborative working sessions. 

Consider the Daily Stand-up. It is meant to be applied at a team level (~7 people) and take no more than 15 minutes. This means that each person has approximately 2 minutes to communicate progress and impediments. Teams new to the stand-up usually takes much longer than 15 minutes to get through their progress as they don’t yet have experience of being brief. Agile brevity means that they must consider what is the highest value information to communication the progress from yesterday, the highest value information that focuses on the work today for potential collaboration, and the specifics of any impediments so others understand it enough to potentially help, all within a very timely manner.  

Agile brevity also applies to Refinement and Sprint Planning ceremonies. Within the context of these ceremonies, there is typically a timebox on how long is spent on each user story. As there is less structure in refinement or planning ceremonies than a daily stand-up, the hyper-focus of crisply asking the right questions to understand the user story is even more important.  The other attribute of agile brevity is determining if your question or information is of greater value than another person’s question or information. In other words, many factors should be quickly swirling in your head before you speak. 

Agile brevity is a combination of art and skill keeping one’s comments or questions as clear, concise, and value-added on the topic at hand as possible. It keeps people mentally focused, keeps working sessions tight and to the point, and ensures the highest value information and questions get discussed. While its called “agile brevity”, it isn’t specific to Agile and can be used to make any ways of working more efficient, effective, and value-added. If you find your working sessions often running long, consider trying this technique.   

Requirements Tree: Focusing your efforts on the highest value work

Requirement is a nebulous term.  It can mean something large like a strategy, to smaller items like features, user stories, or tasks. People often throw around the word requirement without a strong sense of the type of requirement it is or the level it belongs. It is important for clarity and common understanding across organizations and teams. Otherwise, it can be quite confusing as to which level people are discussing. 

To gain this common understand of the various levels of requirement, I recommend starting by establishing a requirements tree.  It is a structure that represents the relative hierarchy amongst various requirements elements within your enterprise. It makes it clear how requirements levels are connected. For example, a feature is a requirements element that is at the larger than a user story, so I would expect to find multiple children (aka, user stories) to the build a feature.  Think of it as your requirements lineage. 

What are advantages of creating a requirements tree? First, it ensures that requirements elements at the lower level (aka., the children) are aligned to higher level and presumably high value requirements elements. This ensures that you are putting all of your company’s effort on the highest value work. Second, it helps you determine if there are random requirements that made their way in through a back door.  Third, the requirements tree provides context of the level of requirement being discussed and traceability in the hierarchy.  

What are the various requirements elements and hierarchy? There is no industry standard group in either and they can vary from enterprise to enterprise. The key is to establish yours.  I like to start with corporate strategy and end with tasks as illustrated in the figure. 

Once you establish the levels of your requirements tree, it is important to craft a definition to describe each level.  Using the requirement levels from the figure, here is how I describe each level.  A strategy sets  direction for the enterprise.  An idea is a high customer value and outcome-based opportunity.  An increment is an end-to-end slice of the idea to provide value and validate of the idea.  An epic is a function or feature.  A user story is a requirement that fits into a sprint of a week or two and has one persona.  A task is a very small unit of work that incrementally builds the user story. 

In addition, when you have the requirements tree and definitions of each level, you can align roles of who should be working on those levels with expectations and outcomes of each level. 

You may notice that instead of putting the strategy on top, I place it on the bottom.  I do this to represent the strategy as the trunk of the tree as this should provide guidance for how the smaller requirements elements (e.g., ideas, increments, epics, user stories, and tasks) should grow. While your strategy may adapt over time based on customer feedback and the changing marketplace, it should guide the type of work you may consider working on. 

The key to your requirements tree is for you to establish one that makes sense for the type of work you do.  For example, if you only have one division in your company, then a division strategy isn’t necessary.  You may also work with business requirements so place them in the right level for your tree. Those that may consider creating a requirements tree are a combination of executives, portfolio, product owners, and team members.  Once crafted, it should be shared with everyone for a common understanding and a way to validate that the work at the team level is aligned with the highest value work.

Note: For more information on the Requirements Tree, read Chapter 15 of the book "The Agile Enterprise".